Skip to content
This repository has been archived by the owner on Jul 24, 2024. It is now read-only.

Leverage camel-k to materialize syndesis-meta #7686

Open
lburgazzoli opened this issue Jan 24, 2020 · 0 comments
Open

Leverage camel-k to materialize syndesis-meta #7686

lburgazzoli opened this issue Jan 24, 2020 · 0 comments
Labels
Epic Use by ZenHub, typically also for user stories group/camel-k group/extension Tools for developing Syndesis extensions group/meta Service for connector meta-data and verification of connections group/operator Infrastructure operator related group/server REST backend for managing integrations

Comments

@lburgazzoli
Copy link
Collaborator

lburgazzoli commented Jan 24, 2020

This is a...


[X] Feature request
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Documentation issue or request

Description

The syndesis-meta service is s spring-boot based application (fat-jar) that provides metadata validation, retrieval and manipulation facilities for all the connectors known to syndesis at build time.

This closed world assumption as some limitations:

  • extension developer, can't provide functionalities such as parameter validations as there's no way to have component/action extensions taken into account by syndesis-meta
  • libraries extensions are made available to the syndesis-meta through a persistent volume shared between the syndesis-server and syndesis-meta PODs which adds additional maintenance costs and breaks immutability
  • the more connector will be developed and added to syndesis the higher the chance to have incompatible libraries on the classpath will be
  • the service can't take advantage as platform such as Knative and scale to zero when there's no requests because of a long startup time

As syndesis is heading to use camel-k as engine to deploy integrations, we can leverage it also to materialize the syndesis-meta service which would provide the following benefits:

  • meta-service can be re-built when the connector are added through the extension mechanism or when there is the need to provide additional dependencies such as jdbc driver
  • meta-service can be deployed as a monolith as it is today but on Knative the meta-servicew can be split into multiple service each one providing metadata facilities for a single connector or a subset of the known ones

This of course does not come for free as there some related changes:

  • store extensions in a s3 compatible object storage( instead of a database as it is today) with a structure compatible with maven repositories so later camel-k can retrieve it as any other dependency Let dependencies be defined using file URLs apache/camel-k#1227 (detecting it is an extension is a camel-k enhancement support for dependencies archive apache/camel-k#334)
  • enhance the syndesis-operator to generate camel-k integration to properly materialize syndesis-meta service(s)
  • enhance the syndesis-server to generate a CRs the syndesis-operator can leverage to materialize syndesis-meta service(s)
    image
  • extension can be deployed straight to the s3 storage and discovered by syndesis via CRs
@lburgazzoli lburgazzoli added group/extension Tools for developing Syndesis extensions group/meta Service for connector meta-data and verification of connections group/operator Infrastructure operator related group/server REST backend for managing integrations status/never-stale Marker that this issue should not be marked as stale labels Jan 24, 2020
@phantomjinx phantomjinx added the Epic Use by ZenHub, typically also for user stories label Jul 3, 2020
@zregvart zregvart removed the status/never-stale Marker that this issue should not be marked as stale label Jan 5, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Epic Use by ZenHub, typically also for user stories group/camel-k group/extension Tools for developing Syndesis extensions group/meta Service for connector meta-data and verification of connections group/operator Infrastructure operator related group/server REST backend for managing integrations
Projects
None yet
Development

No branches or pull requests

3 participants