Skip to content

Instantly share code, notes, and snippets.

@cmwylie19

cmwylie19/DEG-14.md

Last active December 30, 2024 16:22
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save cmwylie19/1e7565d4bf7860a89a87931dbae64c0b to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save cmwylie19/1e7565d4bf7860a89a87931dbae64c0b to your computer and use it in GitHub Desktop.
Download ZIP
Notes for DEG-14.
Raw
DEG-14.md

Assess ability to deploy vanilla Teiid to replace JDV

Acceptance Criteria

Complexity of deploying Teiid

There is a high degree of complexity stemming from deploying Teiid due to the following:

  • Not a straight-forward build, we would need to track down specific settings used to deploy JDV and attempt to translate those to Teiid. This may or may not be straight forward.
  • We currently do not have the infrastructure available to deploy it. More on this in where this could be deployed
  • Due to the fact that the project is no longer maintained, methods of deployment that have worked in the past are no longer viable options.
  • Existing Kubernetes Operator is deprecated and would require a rebuild w/ a modern version of Operator-SDK OR to run on an old depricated version of Kubernetes that is no longer supported.
  • As Joel pointed out, we are not be targeting a simple Kubernetes deployment, instead, we would be relying on other teams and going through a process of requesting infrastructure and creating tenants which would be an undefined amount of time.

Document Concerns

Cons.

  • Teiid is not a 1-1 replacement for JDV due to important features present in JDV but not Teiid. (MAJOR CONCERN)
  • Teiid is not longer maintained (MAJOR CONCERN), which means it is not necessarily a better choice than JDV, which is also not maintained.
  • Teiid Operator for deploying in Kubernetes is also not maintained and many apiVersions are deprecated.
  • The process of finding infrastructure is a major concern and would take an undefined amount of time, since this would not be part of our team's purview, which would eliminate the possibility of moving fast to address some specific concern.

Pros

  • None

Where this could be deployed

In terms of existing infrastructure, we have none, so this is not viable in and of itself. For the sake of being thorough, i will outline the possiblities.

  • Options for deployment include:
    • A self-hosted OpenShift Based approach which would involve our own tenancy on MP+.
      • This would include requesting a tnenat through a ticket
      • Additional setup would be required around creating "app-codes" and tenants.
    • An EDA-Hosted OpenShift based approach which would involved the EDA Platform team with the point of contact Greg Neighbors for very high level discussions about the feasibility and resourcing available for such a solution. The technical implementation details would likely involve Bink Binkowski ([email protected]).
    • A bare-metal or similar approach would involve DMT, with the top level point of contact being Rathan Aukunuru ([email protected]) with technical implementation likely involving Avinash Singh ([email protected])

How to actually deploy Teiid

Info based on upstream teiid documentation and installation guide

  • Step 1: Get an environment
  • Step 2: Clone and Build
  • Step 3: Decide on the installation mode (Standalone or Domain)
# standalone profile with specific configuration
<jboss-install>/bin/standalone.sh -c=standalone-teiid.xml

# standalone 
<jboss-install>/bin/standalone.sh

# domain mode 
## On controller (master) node 
<jboss-install>/bin/domain.sh


## on worker/secondary (slave) node
<jboss-install>/bin/domain.sh
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment