Syndesis: Clarify ways to install Syndesis

[christophd]

This is a...

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

Description

We should clarify the different ways how to install Syndesis.

Let's collect all known install scripts and scenarios in this issue and see how we can consolidate or remove obsolete things in order to have less maintenance effort.

[christophd]

So I am aware of the following scripts dealing with Syndesis installation:

• tools/bin/syndesis
  
  
  
  • subcommand minishift --install
  
  
  • subcommand crc --install
  
  
  • subcommand install
  
  
• tools/bin/install-syndesis
• curl -sL https://syndes.is/start (https://github.com/syndesisio/syndesis.io/blob/master/static/start#L29)
• app/build.sh
  
  
  
  • subcommand install --local -p syndesis -y
  
  

Anything else I am missing?

[zregvart]

I think all of those scripts end up using the tools/bin/syndesis shell script.

[christophd]

@zregvart true except tools/bin/install-syndesis which is something different.

It says:

# ====================================================
# Standalone script for deploying syndesis
#
# This is an alternative to "syndesis install". If you
# have the choice, try to use "syndesis install" as
# it has more features

Do we really need all those entry points into the very same binary then? And why do we have something like syndesis install --local?

[zregvart]

Do we really need all those entry points into the very same binary then? And why do we have something like syndesis install --local?

Nope, we need something to support local development and we need the install for end users via operatorhub.io. Nothing else.

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[slim-benhammouda]

Hello,
Is there a documentation describing how to install Syndesis in production? All the documentation is about minishift!!
Any documentation about installing Syndesis on kubernetes?
Many thanks,

[zregvart]

@slim-benhammouda we're working on a way to install and run on Kubernetes follow #6200 for updates.

[SvenC56]

I also wanted to ask for a production installation Guide on OKD/ OpenShift. I'm not 100% sure how to setup a custom domain and enable data-virt (Teiid).

Where do I have to specify these settings?

# Switch to admin
$ oc login -u system:admin

# Register CRD and grant permissions to "developer"
$ syndesis install --setup --grant developer --cluster

# Switch to account developer
$ oc login -u developer

# Install Syndesis
$ syndesis install

[zregvart]

@SvenC56 I think you can enable addons by specifying --app-options " --addons dv" on syndesis install. We have this documented for syndesis minishift I think it should work for syndesis install as well.

Even if you install without the addon, the addon can be enabled by editing the Syndesis custom resource (e.g oc edit syndesis app) to add:

spec:
  addons:
    dv:
      enabled: true

[zregvart]

To summarise, this is my understanding, feel free to add your thoughts on this as well.

As a developer:

• use syndesis CLI to install on Minishift (syndesis minishift) or CodeReady Containers (syndesis crc)
• use the operator binary (syndesis-operator) with --dev to install on arbitrary OpenShift cluster

This seems okay to a point, I'm not entirely sure we should focus on specific tooling on OpenShift but rather make it a prerequisite. It is very convenient to run syndesis minishift --install and have it setup everything but it's also a burden on us to maintain that. I think we could make it a prerequisite that as a developer you need to provide a OpenShift cluster (Minishift or CRC based, we should not care) and start with that assumption in the tooling.

As end user:

• use start script (https://syndes.is/start) to install on minishift (uses syndesis CLI under the hood)
• use syndesis CLI to install on arbitrary cluster (syndesis install)
• use the operator binary (syndesis-operator) to install on arbitrary cluster
• install via OperatorHub.io

That to me seems too many ways to install, I think as an end user we should focus on the OperatorHub.io and provide the installation via the operator binary as an alternative.

I think there are usability issues with the operator binary, it could be much simpler and it could be more robust in feature/permission detection, but I find it easier to maintain and it is cross platform vs bash scripts which cause issues for Windows users.

[phantomjinx]

Hey Zoren,

So I have witnessed some of these issues since working on kubernetes support.

One of the take-aways of kubenetes is that it promotes scripting even to the point of changing user or namespace. The reason Openshift has the 'oc' command and does not just use 'kubectl' is it provides important value-add features, eg.

• oc login -> use and authentication provider to authenticate then changes the current context to the correct namespace/project;
• oc new-project -> builds on 'kubectl new-namespace' by adding an admin rolebinding into the namespace so the user can do stuff.

In the case of the operator binary, it is true it does a lot to get things going but even it has to fundamentally do 3 things:

1. ${binary} install cluster
2. ${binary} grant --user ${user}
3. ${binary} install

Steps 1 and 2 require admin privileges whilst step 3 requires ${user}. This immediately implies a procedure (that is just inviting a wrapping script):

1. Login as admin
2. ${binary} install cluster
3. ${binary} grant --user ${user}
4. Login as user
5. ${binary} install

(Such a script has become even more necessary in the kubernetes world as, for example, auth-provider secrets have to be created as separate pre-requisites)

Where does this get us?

• I agree that our scripts are trying to do too much, although there is a trade-off with trying to ensure as close to a turn-key solution as possible;
• With kubernetes support happening soon (ish), the assumption of a cluster should be sufficient for our purposes;
• Developers soon develop their own ways of working but it can be dis-orientating when we first start so maybe a degree of hand-holding is helpful in the short-term (not so much in the long-term);
• I personally see the operator-binary as a power-user app that should be shirnk-wrapped via simpler scripts.

So endeth my pennieth.

PGR

---

Paul Richardson

• @enigmajx (https://twitter.com/enigmajx)

"There is no operating system on the planet that can withstand a determined assault from a clueless user."

April 22, 2020 11:25 AM, "Zoran Regvart" <[email protected] (mailto:[email protected]?to=[e-mail])> wrote:
To summarise, this is my understanding, feel free to add your thoughts on this as well.

As a developer:
* use syndesis CLI (https://syndesis.io/docs/cli/syndesis/) to install on Minishift (syndesis minishift) or CodeReady Containers (syndesis crc)
* use the operator binary (syndesis-operator) with --dev to install on arbitrary OpenShift cluster
This seems okay to a point, I'm not entirely sure we should focus on specific tooling on OpenShift but rather make it a prerequisite. It is very convenient to run syndesis minishift --install and have it setup everything but it's also a burden on us to maintain that. I think we could make it a prerequisite that as a developer you need to provide a OpenShift cluster (Minishift or CRC based, we should not care) and start with that assumption in the tooling.

As end user:
* use start script (https://syndes.is/start (https://syndes.is/start)) to install on minishift (uses syndesis CLI under the hood)
* use syndesis CLI to install on arbitrary cluster (syndesis install)
* use the operator binary (syndesis-operator) to install on arbitrary cluster
* install via OperatorHub.io
That to me seems too many ways to install, I think as an end user we should focus on the OperatorHub.io and provide the installation via the operator binary as an alternative.

I think there are usability issues with the operator binary, it could be much simpler and it could be more robust in feature/permission detection, but I find it easier to maintain and it is cross platform vs bash scripts which cause issues for Windows users.

—

You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub (https://github.com/syndesisio/syndesis/issues/6997#issuecomment-617691688), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AAMO7BFZISLIBGPOCQJ4ZVDRN3A3HANCNFSM4JEBUI6Q).

[kevinmershon]

Is there a documentation describing how to install Syndesis in production? All the documentation is about minishift!!

+💯 Syndesis needs README/quick start guides specifically for "This is how you get install Syndesis to GCP or AWS", aimed at non-devops engineers and people who are coming at this from end-user experience using industry-leader IPaaS platforms like Boomi and Jitterbit, and some transparency about the infrastructure costs to run it.

I spent hours and hours scouring Google looking for "quick start"-esque guides to deploy Syndesis to GCP....and then to deploy Minishift to GCP...and then finally how to deploy OpenShift to GCP, none of which led me to the actual guide of using OpenShift-Installer. It ended up being a Youtube video from 2016 that pointed me in the right direction. And none of that documentation stated that OpenShift is $50/month to Red Hat, on top of my hosting costs.

[blaggacao]

Maybe the project _could_ benefit from reutilizong some or all components from https://skaffold.dev/

(Over-simplieified) Synopsis:

Dev: skaffold dev
Prod: skaffold run

I personally prefer to stop by skaffold render and then let it be picked up by fluxcd.

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!