[JBoss JIRA] (TEIIDSB-27) Created targeted documentation
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-27?page=com.atlassian.jira.plugin... ]
Ramesh Reddy updated TEIIDSB-27:
--------------------------------
Fix Version/s: 1.2.0
> Created targeted documentation
> ------------------------------
>
> Key: TEIIDSB-27
> URL: https://issues.jboss.org/browse/TEIIDSB-27
> Project: Teiid Spring Boot
> Issue Type: Task
> Components: documentation
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 1.2.0
>
>
> It's expected that all developer oriented aspects will be self documented with javadoc and examples (udfs, pom options, configuration, custom extensions, etc.). However the Teiid ddl, sql - and in particular the presentation of topics that were presented separately such as data roles - need to be covered by documentation that does not reference topics such as Designer, wildfly/cli, xml vdbs, etc. We should probably also discuss if it makes any sense to still offer the local adminapi.
> We expect to receive some input from the documentation group around doc structure and strategies for generating specific documentation sets off of a master. At a high level we have:
> Administrator’s Guide - WildFly specific and should mostly be replaced by examples
> Caching Guide - References adminapi, Teiid JDBC, xml vdbs..
> Client Developer’s Guide - Teiid JDBC
> Developer’s Guide - References WildFly and several arche-types are specific to WildFly/JEE - should mostly be replaced by examples
> Embedded Guide - Should mostly be replaced by examples
> Reference Guide - References XML vdbs
> Security Guide - WildFly specific and should mostly be replaced by examples, but a lot is TDB
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (TEIIDSB-51) Define expectations for runtime metadata
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-51?page=com.atlassian.jira.plugin... ]
Ramesh Reddy updated TEIIDSB-51:
--------------------------------
Fix Version/s: 1.2.0
(was: 1.1.0)
> Define expectations for runtime metadata
> ----------------------------------------
>
> Key: TEIIDSB-51
> URL: https://issues.jboss.org/browse/TEIIDSB-51
> Project: Teiid Spring Boot
> Issue Type: Feature Request
> Reporter: Steven Hawkins
> Priority: Major
> Fix For: 1.2.0
>
>
> At a high level there are potentially three modes for our ddl:
> 1. Interactive - there was some work toward this, but it needed to only be a "developer mode" as it would reload the vdb on each metadata change. There is a lot about the transactionality of DDL updates that our current simplistic metadata model does not support, which makes this hard to fully implement. We haven't talked about this much in relation to Teiid Spring Boot, but ideally there should be a way for developers to test incremental changes without full rebuilds.
> 2. Dynamic - the term is a bit dated, but this refers to any vdb that performs import from a metadata repository that has runtime dependencies. By design this allows for a simple vdb definition and options for caching or re-importing on reload. In a container environment metadata caching no longer makes sense unless we use a volume. Depending upon your viewpoint allowing for runtime import of metadata is potentially a point of mutability that is also not needed in a container environment.
> 3. Static - much like our old .index designer vdbs there are benefits to having the full metadata already available to the vdb/image. There is a lot of work that we do lazily at runtime that can be moved to an earlier phase - primarily generating the rest and odata layers, but it would also include the pg system table materializations. For Teiid Spring Boot or usage in containers in general what this would look like is a build phase for the vdb such that it could obtain appropriate metadata and initialize as much as possible statically (eventually for quarkus vm snapshotting). The only metadata that would not be fresh potentially would be the costing metadata - however that is problematic as is and will eventually need a progressive optimization strategy employing a persistent store.
> As of now we are currently focused just on #2. As we look toward operators, we should start thinking about #3.
> #1 would come into play if/when we start looking at local development options using vs code.
> We can treat this issue as an epic and a place to centralize discussion.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (TEIIDSB-4) Provide rest access with SpringBoot
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-4?page=com.atlassian.jira.plugin.... ]
Ramesh Reddy commented on TEIIDSB-4:
------------------------------------
For the return type and additional automatic mapping, this below is what I am considering to implement.
When working in Syndesis, or even in standalone, if the above maven-plugin is configured with access to an OpenAPI (swagger.json) document, then it will match `OperationId` from the OpenAPI document with the virtual procedure name in the VDB, if there is a match including the parameters, then the metadata from the swagger document is applied on the procedure (even in the absense of `REST:` metadata on procedure) and necessary scaffolding is generated.
The nice thing about this is, it will match the needs of Syndesis, but needed metadata is external to VDB which is different from before. But, I am not bringing this as an alternative, but in addition to current `REST:` based metadata, giving preference to `REST:`, in absence of the metadata, it will match with swagger document for futher enhancement.
> Provide rest access with SpringBoot
> -----------------------------------
>
> Key: TEIIDSB-4
> URL: https://issues.jboss.org/browse/TEIIDSB-4
> Project: Teiid Spring Boot
> Issue Type: Feature Request
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Priority: Major
> Fix For: 1.1.0
>
>
> The current rest access layer is based upon the generation of a war with deployment hooks in wildfly. There should be a build-time or similar mechanism to expose rest with spring boot.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (TEIIDSB-92) Provide an openshfit example of a secure transport
by Steven Hawkins (Jira)
Steven Hawkins created TEIIDSB-92:
-------------------------------------
Summary: Provide an openshfit example of a secure transport
Key: TEIIDSB-92
URL: https://issues.jboss.org/browse/TEIIDSB-92
Project: Teiid Spring Boot
Issue Type: Sub-task
Components: OpenShift
Reporter: Steven Hawkins
Assignee: Ramesh Reddy
Until we have kerberos support, usage of the pg transport will likely need to be secure to prevent plain-text username/password being sent unencrypted.
It should also be a general option to enable secure transports from our ui. External exposure is covered in TEIIDSB-86.
We should use the private key from either based upon a self-signed certificate or using service signing certificates. I'll provide an example demonstrating one of those approaches.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (TEIIDSB-92) Provide an openshfit example of a secure transport
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-92?page=com.atlassian.jira.plugin... ]
Work on TEIIDSB-92 started by Steven Hawkins.
---------------------------------------------
> Provide an openshfit example of a secure transport
> --------------------------------------------------
>
> Key: TEIIDSB-92
> URL: https://issues.jboss.org/browse/TEIIDSB-92
> Project: Teiid Spring Boot
> Issue Type: Sub-task
> Components: OpenShift
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
>
> Until we have kerberos support, usage of the pg transport will likely need to be secure to prevent plain-text username/password being sent unencrypted.
> It should also be a general option to enable secure transports from our ui. External exposure is covered in TEIIDSB-86.
> We should use the private key from either based upon a self-signed certificate or using service signing certificates. I'll provide an example demonstrating one of those approaches.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (TEIIDSB-92) Provide an openshfit example of a secure transport
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-92?page=com.atlassian.jira.plugin... ]
Steven Hawkins reassigned TEIIDSB-92:
-------------------------------------
Assignee: Steven Hawkins (was: Ramesh Reddy)
> Provide an openshfit example of a secure transport
> --------------------------------------------------
>
> Key: TEIIDSB-92
> URL: https://issues.jboss.org/browse/TEIIDSB-92
> Project: Teiid Spring Boot
> Issue Type: Sub-task
> Components: OpenShift
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
>
> Until we have kerberos support, usage of the pg transport will likely need to be secure to prevent plain-text username/password being sent unencrypted.
> It should also be a general option to enable secure transports from our ui. External exposure is covered in TEIIDSB-86.
> We should use the private key from either based upon a self-signed certificate or using service signing certificates. I'll provide an example demonstrating one of those approaches.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (TEIIDSB-55) Provide GoogleSheets support
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIIDSB-55?page=com.atlassian.jira.plugin... ]
Ramesh Reddy resolved TEIIDSB-55.
---------------------------------
Resolution: Done
I will resolve this for runtime Teiid purpose, and we need to revisit the additional property when UI support comes along, hopefully, by then above issue is resolved.
> Provide GoogleSheets support
> ----------------------------
>
> Key: TEIIDSB-55
> URL: https://issues.jboss.org/browse/TEIIDSB-55
> Project: Teiid Spring Boot
> Issue Type: Feature Request
> Components: datasource
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Priority: Major
> Fix For: 1.1.0
>
>
> Provide data source support for Google Sheets. Must support the same authentication mechanism as Syndesis.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months