Set up a 3-node Kubernetes cluster in AWS that the core recipe can deploy to. The environment should be easy to recreate if a failure is encountered e.g. by running a script.

The environment should also be accessible from CCI by using SSH for deployment and debugging purposes.

The Circle CI config should include deploying to AWS for both kubernetes and docker swarm recipes. This task is dependant on that there are already AWS instances setup for each of them.

We are today exposing both License and Mira to a Nodeport. We should consider closing these in favor for ClusterIP. Things to consider with this:

• New users trying our service (to see results)
• Our tests in CCI

We already know that there are some steps that needs to be taken when moving from minikube to a cloud provider (Credentials). Make sure we document these steps and that the chart is working in cloud.

A BlackDuck Protex scan failed on this repository.

Number of files needing identification: 5

If you are unsure how this process works, please contact trunk team on Slack.

No more automated issues will be created on this repository until this issue
is closed.

Please prioritize and solve this as soon as possible. If the files
has been identified already, you may ignore and close this issue.

Create a Helm chart for frontira to help customers quickly get started with the frontira stack.

We need to update the core-orchestration examples with the new format for passing a license/LEF to the licenses service.

This task includes to write a set of test cases that validates a deployed configuration of the core recipe. The set of tests should be able to run independent on the orchestration tool being used.

The test cases should be possible to run on a locally set up deployment, but also in a circle ci environment.

This issue contains a checklist of tasks that is needed before repo can be open sourced.

Checklist

• LICENSE file added to repo with a MIT license.
• Linting of code e.g. airbnb for node.js repo.
• Circle CI build to secure quality e.g. linting, tests, docker image.
• Update README.md to contain relevant info for the repo e.g. Contributions
• Add .editorconfig, .gitignore and .gitattributes

We need a good example to show what type of access that is needed to the Kubernetes API for Mira to be able to discover engines.

Kubernetes offers rbac (Role based access controll)
This is something that is enabled when starting your api server with parameter:
--authorization-mode=RBAC
To test this in minikube:
minikube start --extra-config=apiserver.Authorization.Mode=RBAC
If this is enabled you need to give Mira's sidecart container (kubectl) specific permissions to query the api.
More info here:
https://kubernetes.io/docs/admin/authorization/rbac/

Discovery role should be sufficient:
https://kubernetes.io/docs/admin/authorization/rbac/#discovery-roles

Helm and rbac:
https://github.com/kubernetes/helm/blob/master/docs/service_accounts.md
Issue describing the problem with helm and rbac:
helm/helm#2224

Good walkthrou of rbac:
https://docs.bitnami.com/kubernetes/how-to/configure-rbac-in-your-kubernetes-cluster/

Add a section that describes how to setup and run the license service.

Add more info to the README so that people landing directly in this repo can understand what it is. Should not have to start in info repo to get a good understanding. Also link back to info repo for navigability.

When linting the Mira and Engine chart we get an error saying:
[ERROR] templates/: render error in "mira/templates/service.yaml": template: mira/templates/service.yaml:4:20: executing "mira/templates/service.yaml" at <{{template "fullname...>: template "fullname" not defined

[ERROR] templates/: render error in "engine/templates/service.yaml": template: engine/templates/service.yaml:4:20: executing "engine/templates/service.yaml" at <{{template "fullname...>: template "fullname" not defined

Error from server (BadRequest): error when creating "license-service-deployment.yaml": Deployment in version "v1beta1" cannot be handled as a Deployment: v1beta1.Deployment.Spec: v1beta1.DeploymentSpec.Template: v1.PodTemplateSpec.Spec: v1.PodSpec.Containers: []v1.Container: v1.Container.Env: []v1.EnvVar: v1.EnvVar.Name: ReadString: expects " or n, but found 1, error found in #10 byte of ...|[{"name":10083701745|..., bigger context ...|service"}},"spec":{"containers":[{"env":[{"name":1008370174569449,"valueFrom":{"configMapKeyRef":{"k|...

We need to add test cases for verifying that the core helm recipe works in kubernetes. This task includes investigating how this should be tested on a local environment and what kind of verification is needed.

• Add yaml files to be able to deploy core Frontira.

• Add documentation of how to deploy core Frontira.

Circle CI does not allow VMs in a VM in the job pipeline so we need to investigate how to validate a docker swarm configuration of the core recipe.

This task includes investigating if it is possible to set up a docker swarm configuration in Circle CI with only one node e.g. creating the swarm on the machine executor.

The documentation explains how to configure the License Service and QIX Engine to use a license. However, the examples (compose-files, deployment specs etc) do not yet contain this set up since there is no QIX Engine version supporting it.

Once this is supported, update the examples (and documentation).

• Add Docker Swarm compose to run core Frontira.

• Add Documentation how to deploy the compose file

Make sure the core Frontira Helm chart is working on the Minikube

A 3-node static environment for docker swarm in AWS that the core recipe can deploy to and run E2E tests against. The environment should be easy to recreate if encountering failure, e.g. by running a script.

Add support to deploy the Core recipe locally, running Mira in Local mode.

Look into how the templating is working, and start defining the template for Frontira.

• Cleanup of script (move reused configs higher in the templating chain)
• Add documentation around charts (nodeport / loadbalancer)

frontira -> qlik-core

Now we have the frontira helm charts in this repo but we do not package it or push it to any other repository e.g. jfrog.

How should it be distributed and consumed by other repos/services?

The core recipe today will only be validated against AWS deployment, but we also need to validate the recipe in a Google Cloud environment. For this we will need a Google Cloud account.

This task includes to request and find out if, how and when we can get a Google Cloud account that can be used for automatic deployment of the Core recipe.

Update the first inital Readme with what this repo will include, and how the roadmap for it looks like.

Since we now host our own helm chart in mira, that chart should be used instead of the example chart used here.