Catapult 2.0 design

[viovanov]

We should discuss how v2.0 should be implemented:

• goals
• tools
• architecture

[viccuad]

As a start on goals and architecture, see the current ones since October's workshop:
https://github.com/SUSE/catapult/wiki/Architecture-and-implementation#goals

[mudler]

Few thoughts on the goal: I would like to keep it KISS to hack on. @manno had a nice idea to split the core functionalities in another language, but this needs to be well-thought from the beginning, so we don't raise a barrier for contributions.
I really like that the simplicity of bash allowed us to hack on it quite easily.

I'm a bit against using tools like Ansible, Chef and a-like for this. they just build up silos and you need then to figure out support for different linux distributions (yes, they advertize they support all of the families, but that's not true).

Said that, shooting some ideas:

Proposal 1 what about a Golang core that reads "recipes" that can be written in a different way, e.g. Gherkin , Yaml . At the end we need to just feed helm and kubectl with different instructions, so it might be a good way to simplify it.

Proposal 2 We could follow the Unix-philosophy on this, and treat the problem like git does with external extensions.
E.g. If we assume that a folder is just our testing environment, containing all the tools needed to deploy, test, and manage a cluster, then we can have N extensions that can interact with the core that are decoupled from it (think it like each extension is just installed as binary catapult-extension1 and then is available as catapult extension1 [...] to the user) .
The core at this point just interacts with holding the metadata in a nice format (we could even also just use git annotations for this)

[mudler]

By the way, formally this would be a v3, there was already a rewrite to v2 quite some time ago: #46

[viccuad]

By the way, formally this would be a v3, there was already a rewrite to v2 quite some time ago: #46

I agree with it being v3, but then we should change the v1 tag: https://github.com/SUSE/catapult/releases

[f0rmiga]

+1 on the UNIX philosophy proposed by @mudler. It should be easy to implement the catapult binary in Go and the extensions still be in another language whenever needed.

[jimmykarily]

I like number 2 plus @f0rmiga suggestion to be able to use whatever language for the subcommands. So introduce some convention on where the executable of the subcommand should be and then let it be whatever it wants (possibly contain all files related to a subcommand under the same directory). 👍

[viccuad]

+1 on option 2, for the core: FSM, options handling, etc.

It would be nice to not lose all functionality that is already there. For that, we could move the "header" that all scripts {module,backend}/foo/*.sh operating on the buildfolder have, into the core. Eg:

catapult/modules/tests/kubecf-test.sh

Lines 1 to 7 in 2192d57

	#!/bin/bash
	# This script runs a test suite on kubecf
	. ./defaults.sh
	. ../../include/common.sh
	. .envrc

That way they would be plain scripts without sourcing nor using bash functions: they should work if run outside of catapult against whatever helm, kubeconfig, etc. Then we can drop the "header" later and start consuming only executables.
The scripts consume env vars as options, to branch on logic. It would be nice to provide an executable that type-checks options, provides correct defaults, is able to change value of options for that specific buildfolder, etc.

[mook-as]

Looking at #160, it would be nice if the configs can be passed in via something other than environment variables. They are typo prone (they have to be set repeatedly, and there is no feedback if there's a mistake as they are just silently ignored).

I have no opinion on if the individual modules take configs in environment variables; I only ask that the input to the system (from the user) is in some other format.

[jimmykarily]

@mook-as it already supports the CONFIG env variable (https://github.com/SUSE/catapult/blob/master/include/common.sh#L9) but it's not well documented (if at all). Also it could be improved a lot. E.g. it could show a warning or an error when an unknown settings is provided (to avoid typos that would otherwise lead to ignored settings).

[mudler]

Looking at #160, it would be nice if the configs can be passed in via something other than environment variables. They are typo prone (they have to be set repeatedly, and there is no feedback if there's a mistake as they are just silently ignored).

I have no opinion on if the individual modules take configs in environment variables; I only ask that the input to the system (from the user) is in some other format.

It's documented here https://github.com/SUSE/catapult/wiki/Deployment-file

[viccuad]

I totally agree on moving away on env vars as options. I'm just proposing having it interim for the internal logic, to not rewrite all scripts. But maybe it's moot, and it's easier to rewrite or refactor using an executable that queries for options.

[viccuad]

I would be happy to come up with requirements that could go into a production lifecycle manager for CAP.

Another feature request in that vein:
As a user/customer, I would like to have a default values.yaml for the shipped version (eg: cloudfoundry-incubator/kubecf#711), and have catapult provide a changed-values.yaml, after selecting some specific catapult options/profiles.
That changed-values.yaml would be automatically added to a local git repo with the history of that cluster. Makes it easy to check, revert, and upgrade CAP deployments.

[prabalsharma]

We need to first list out current problems before brainstorming on how to solve them. "What are we trying to solve?", is a very important question to avoid over engineering to reach a basic goal of helm install with different helm parameters based on scenarios.
I don't mind bash.

Few of the issues with current catapult which comes to my mind:

1. env vars
2. too many defaults*.sh
3. similar names makes it less intuitive. make sub-folders names and file names more intuitive #123
4. too many folders with no readme, does not help Documentation in code base #124

There should be 1 file to handle all values. Proper restructuring of folders and intuitive file names, is important.

I am not too concerned with supporting old functionality (as long as it does not hamper us). We can just use versioning and move on to improve the tool. After all its not a product.

Our most important goal is "quick iterations during release cycle" (more important goals are already part of catapult).

There were some talks on changing definition of catapult as well. In terms of running tests. We should have that discussion as well, because limiting catapult's definition from its current one, will lead to decision on engineering effort for v3 and its worth.(@satadruroy )

proposal 2 from @mudler sounds interesting. It will be nice to see some example in our upcoming meeting regarding this or some discussion on :

• What will the core look like?
• What will the extensions look like?
• Can we repurpose present scripts to form the core?
• How will this proposal looks from CI's point of view?
• How often we will have to make changes to the core?
• What will define extensions? Will they be based on CAP versions or IaaS? Won't there be a lot of duplication as the changes to CAP deployments are trivial and K8 deployment is almost static.

[satadruroy]

With regards to running tests the broader question is around separation of concerns between CI and Catapult. It seems at this point,

Catapult is responsible for :

• Setting up clusters for various backends (Kind/minikube/CaaSP on ECP/cloud.suse.de/somewhere or public cloud platforms)
• Deploying SCF/KubeCF in various specified configurations (e.g. with LoadBalancer services or with Ingress Controller, internal or external DB)
• Setting up DNS entries, either using magic DNS for on-prem setups or using something like external-dns for public clouds
• Tearing down the cluster

CI can use the interface to ask for a) specific backend b) deploy KubeCF in a specific configuration and get a kubeconfig back. At that point, It is or it should be CI’s responsibility to run various test suites (which may differ depending on if it’s a KubeCF CI or CAP CI) and at the end of the test run ask Catapult to tear down the cluster. IoW, if setting up and running the tests is also part of Catapult now they perhaps should not be.

I’m sure I missed other stuff so feel free to add to above.