Skip to content

Latest commit

 

History

History
43 lines (29 loc) · 2.78 KB

dv-development-options.adoc

File metadata and controls

43 lines (29 loc) · 2.78 KB
Raw

Virtualization development Options

Table of Contents

A User can develop a Virtualization (VDB) in a couple different ways. Each of the options has advantages and disadvantages. In the end all options use the Operator to deploy the Virtualization to OpenShift and yield exactly the same virtualization runtime with the same features. The choice depends upon the complexity of the project and the need for testing on and off the OpenShift platform.

Virtual Database defined as DDL on Operator Custom Resource (CR)

Using this option the User can directly define the VDB contents in the form of DDL in the Custom Resource VDB definition and use the Operator to deploy this virtualization. When deployed, the Operator will put together an S2I build on OpenShift based on dependencies it can glean from the VDB artifact. This may fail if certain dependencies are not found - such as if the developer omits the dependencies of JDBC drivers, etc.

Pros

  • Simple and minimalistic

  • All the code and configuration related to this virtualization is in one single file.

  • Easy management.

Cons

  • The Custom Resource YAML file can quickly become large with the amount of required DDL.

  • The VDB is embedded in the Custom Resource YAML file

  • More difficult to version the VDB independently.

  • When working with multiple environments, properties need to be moved to config-maps or secrets to be independent of the Custom Resource VDB definition.

Find an example of a DDL based VDB here.

Using Virtualization as Maven Artifact

Using this option you can define a virtualization as a maven artifact. Basically, instead of providing a DDL file as a Virtualization, you can provide a particular Maven artifact as a Virtualization.

Teiid provides tools in the form of Maven plugins to convert a given DDL file into a maven artifact that can be pushed to a maven repository with a given version defined in your pom.xml file.

From then on, this artifact can be deployed directly using the Operator. This is an advanced option. However it may be suitable for projects with some level of complexity, as this provides the most flexible options. Typically this can be developed as a multi-module maven project, with vdb sharing when using the vdb-import feature.

Pros

  • Flexible, clean separation of DDL code that represents the VDB and configuration.

  • Suitable for deployment into multiple environments.

  • Versioning is done at the VDB level.

  • A must have when using the vdb-import feature to import this VDB into other vdbs.

  • Virtualization can be sharable with other projects and other teams in a consistent way.

  • Consistent with CI/CD workflows.

Cons

  • The User is required to have Maven working knowledge.

Find an example DDL based VDB here.