Adding support for presets

[sa-cloud]

@safchain, @lebauce, @eranra, @dubek, @hunchback, @KalmanMeth,

We would like to suggest + contribute an enhancement to the SkyDive planned Helm and Operator.   SkyDive includes several modules (Core, UI, Exporter…) and many configuration parameters, each with its respective config options. SkyDive can be used as a network analyzer, as a network collector and in other use cases. The current Helm and Operator offer default values to the many config params and will define which modules will be installed by default. As things stand today, the admin/user need to gain considerable expertise to configure SkyDive correctly (or use the defaults). 

To make SkyDive more approachable by admins and users targeting different use cases, and enable reasonable first experience with the tool, we would like to suggest that the Helm and Operator will support several pre-sets (each with a use case in mind). The admin/user will be able to choose between the pre-sets. Each pre-set will determine if and what set of default values will be used and if and what SkyDive modules will be loaded.

Suggested implementation:

1. In the contrib/helm/values.yaml we will generate separate sections for each preset under Values.{presetname}... whenever we need separate configs for presets. 
2. In deployments yamls such as contrib/helm/temlates/deployment-analyzer.yaml, we will add a condition based on the presetname. If no presetname was defined, the current defaults will be used. If presetname was defined, the appropriate Values.{presetname}... will be used whenever it deviates from the default  + the appropriate modules will be loaded .
3. If an admin/user deploys using helm, he will be able to activate a preset for example using "--set" by defining the presetname.
4. If an admin/user deploys using operator, we suggest to prepare a separate crd file and an accompanying cr file using the same name (which will also define the presetname). The cr will further include the mandatory parameters that the user must configure when using the preset (e.g. url of the object store to which data need to be sent when using skydive as a collector). 

[hunchback]

@sa-cloud - can you provide some examples for presents being used in official (which exists in the respective public hubs) helm and operator implementation?

[sa-cloud]

@hunchback, the official examples are Prometheus and Spark. Each of those operators (and many others) suggest several deployment options (defined each by it's own separate crd). Spark suggests the options: 1. Sparc Cluster 2. Spark Application 3. Spark History Server Prometheus has: 1. Prometheus 2. Prometheus Rule 3. Service Monitor 4. Alert Manager

We called these different options “presets” as they can control what is being deployed and the default configuration that is being used.

[safchain]

@sa-cloud sounds like a good approach to me, please note that the helm thing has been moved to a dedicated repo: https://github.com/skydive-project/skydive-helm

same for the operator, even if there is nothing currently: https://github.com/skydive-project/skydive-operator

[sa-cloud]

@safchain, @lebauce, @hunchback,

https://github.com/skydive-project/skydive-operator/pull/1 https://github.com/skydive-project/skydive-helm/pull/1

In helm: exporter section was added under values.yaml, --set exporter.enabled=true activates the "exporter pre-set" making the SkyDive analyzer start with an additional exporter container. In this case the user also must specify the S3 endpoint and the credentials (either api key or access and secret). By default exporter.enabled is set to false, so installation without --set to this parameter creates default Skydive installation with no changes.

In operator: The operator is generated from the above helm version, that includes exporter component. The operator watches 2 custom resources - 1 for regular SkyDive option, the other is for specific "SkyDive as netflow collector" option, pre-configured and ready, requiring only few specific user configurations (mainly the the S3 endpoint and the credentials).

The exporter image is currently set to private repository location and should be set to the public location, once it is made available.