nuvo/orca

Advanced CI\CD tool for Kubernetes and Helm, Environments as Code

orca's Issues

[meta] fix tests - create a code coverage file successfully

Extend testing coverage

We currently have very little unit testing done, and the ones we do, don't conform to go standard testing mechanism. Running go test ... produces very little data, and no code coverage.
orca is pretty complex and has lots of moving parts, we should invest effort in expanding out test coverage.

As for testing and assertion frameworks, I suggest we use ginkgo and gomega which have strong capabilities and extensive functionality. I've had experience with both of them in the past and while they tend to be a bit verbose, it isn't necessarily a bad thing while running tests.
The challenging part will be how to test cobra functionality, but I guess we can figure it out.

We can start from the various utils functionality and work from there.

cc @maorfr

Implement environment validation

Once environment is created using orca deploy env we need to validate that the environment is valid.
As a first step - need to implement orca validate env that will make sure that all pods are running and ready.
The same function should be executed as part of orca deploy env with a time frame, similar to kops cluster validation.

[deploy/env] static environment update is broken

This is true for versions 0.8.0 and 0.9.0, and will be fixed in version 0.9.1
Since in 0.8.0 we introduced a breaking behavior, deployments to static environments would change nothing in the environment.

Ability to override values on per-chart basis

Hello there! @hagaibarel @maorfr :)

First of all, I want to say that Orca looks great! It's fascinating to see how much it evolved since the very beginning of Nuvo's CI/CD.

While using it lately, I came up with an idea of what can be improved, and I was wondering what do you think about the usefulness of having this feature in the mainline repo.

Orca supports two ways of overriding default chart values:

1. using command line param --set;
2. via a YAML file packaged together with a chart.

However, neither of them covers a major case: when you need to change values only for some charts without knowing values during charts packaging (e.g., number of replicas of a service). So I was thinking about adding an ability to override values during deployment on a per-chart basis.

Currently, I see a couple of ways to implement this feature:

1. Change the structure of Orca's charts.yaml
2. Add a CLI param that takes keys with chart name as a prefix (e.g. --chart-set service1.replicas=10)
3. Add a CLI param (e.g. --global-set) that will set values for all charts (current behavior of --set) and change the logic of --set to accept keys with prefixes like in option (2)

All of the options have their advantages and drawbacks. So I was wondering what do you guys think? Which option looks the best to you? Or would this feature be welcomed at all?

Thanks in advance!

No Auth Provider found for name "gcp"

Wanted to try this tool but it doesn't seem to work with a kubeconfig with a gcp auth-provider. My user looks like this:

- name: gke-cluster
  user:
    auth-provider:
      config:
        access-token: <token>
        cmd-args: config config-helper --format=json
        cmd-path: /opt/google-cloud-sdk/bin/gcloud
        expiry: "2019-01-08T12:48:04Z"
        expiry-key: '{.credential.token_expiry}'
        token-key: '{.credential.access_token}'
      name: gcp

Found this possibly related issue: kubernetes/client-go#242

[deploy/env] add ability to specify multiple charts files

In some cases, we want to deploy a dynamic environment, but still use dependencies.

since get env does not get the dependencies, we can define a base file, and override it with versions.
for example:

charts_base.yaml:

charts:
- name: chart1
  version: nil
- name: chart2
  version: nil
  depends_on:
  - chart1

charts_override.yaml:

charts:
- name: chart1
  version: 0.1.0
- name: chart2
  version: 0.2.0

so we expect that when passing the two files, the results would be:

charts:
- name: chart1
  version: 0.1.0
- name: chart2
  version: 0.2.0
  depends_on:
  - chart1

this way, dynamic deployments can take a base predefined file and deploy in order.
as a first step, we will only implement this to override versions, as the use case is for dynamic environments which would not require an override on dependencies.
we can think about a full merge later.

opened on behalf of @haimkabesa

[deploy/env] error in deployment is not always caught by concurrent deployments

When deploying environments, whether in parallel or not, an error may occur.
Currently an error may or may not be caught.

Will try to fix this issue.

Improve error handling in env/chart deployment

Currently we assume that everything went as expected, and internal functions do not throw errors.
We need to add errors to be raised from internal functions, so we do not use log.Fatal in internal functions.
This will also require adding an additional environment state called "failed".

In addition, when an environment deployment encounters a "failed" or "delete" state - the process should stop instead of waiting with a loop back.

Helm3 support

Hello, it would be cool to support helm3, tiller is no longer supported...

thanks