redhat-cop/dash

dash's Issues

Support kustomize as a template type

Utilize CLI Processing Library

Make use of a CLI library to parse input arguments.

Recommend a tool such as Corba as it is the defacto tools in many Kubernetes based projects

Resources get reconciled multiple times.

Because of the way that we set up and manage the tmp directory, the resources generated are being reconciled multiple times. We need to move the management and cleanup of the tmpDir into the ResourceGroup processing, so that for each ResourceGroup, we create and destroy a tmpDir.

Need a way to process OpenShift Templates

support runs across Multiple Kubernetes clusters

Solution for freeform variable substitution in an inventory

support variable hierarchy, such that variables can be set at multiple levels, overriding as they get more specific.

Ability to handle “deltas” and only process changes on consecutive runs if desired

Support a filter capability to only apply a portion of an inventory

@redhat-cop/openshift-applier any thoughts on syntax/implementation?

Introduce helper functions like`init,add` to help users manage their dash repos

@jacobsee I was thinking we could look at folding the applier-cli functionality in here.

support dynamically combining multiple “inventory” definitions to compose a bigger collection of objects making it possible to re-use the same definitions more easily to avoid duplicates

@redhat-cop/openshift-applier

Support --dry-run flag

Dash should support --dry-run mode

• Preview what's about to be applied
• Integrate with other tooling in the kube space (for example ArgoCD custom plugin)

Develop a repeatable way to cut releases that include compiled binaries

nginx example fails to start on deployment

Tested the Dash example. Below is the output:

[root@a1 dash-proto]# go version
go version go1.12.10 linux/amd64
[root@a1 dash-proto]# oc new-project dash-test
Now using project "dash-test" on server "https://api.test.jk308.com:6443".

You can add applications to this project with the 'new-app' command. For example, try:

    oc new-app django-psql-example

to build a new example application in Python. Or use kubectl to deploy a simple Kubernetes application:

    kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node

[root@a1 dash-proto]# oc project
Using project "dash-test" on server "https://api.test.jk308.com:6443".
[root@a1 dash-proto]# go run cmd/dash.go -i examples/default/
2019/10/19 12:39:28 Resource: Raw Manifests, Namespace: 
2019/10/19 12:39:28 Source: /root/git/dash-proto/examples/default/manifests, Dest: /tmp/dash142426629
2019/10/19 12:39:28 Resource: Helm Charts, Namespace: 
2019/10/19 12:39:28 Resource: OpenShift Templates, Namespace: 
Running command: [kubectl apply -f /tmp/dash142426629]
deployment.apps/nginx-deployment created

[root@a1 dash-proto]# oc get pods
NAME                               READY   STATUS              RESTARTS   AGE
nginx-deployment-6dd86d77d-58z2m   0/1     ContainerCreating   0          8s
[root@a1 dash-proto]# oc get pods
NAME                               READY   STATUS              RESTARTS   AGE
nginx-deployment-6dd86d77d-58z2m   0/1     ContainerCreating   0          29s
[root@a1 dash-proto]# oc get pods
NAME                               READY   STATUS             RESTARTS   AGE
nginx-deployment-6dd86d77d-58z2m   0/1     CrashLoopBackOff   7          14m
[root@a1 dash-proto]# oc log nginx-deployment-6dd86d77d-58z2m
log is DEPRECATED and will be removed in a future version. Use logs instead.
2019/10/19 17:52:40 [warn] 1#0: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:2
nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:2
2019/10/19 17:52:40 [emerg] 1#0: mkdir() "/var/cache/nginx/client_temp" failed (13: Permission denied)
nginx: [emerg] mkdir() "/var/cache/nginx/client_temp" failed (13: Permission denied)
[root@a1 dash-proto]# 

Support for freeform templating, like jinja or go templates

Consider capturing metrics around Dash usage and show in cluster dashboards (i.e.: use prometheus to capture data to show in a grafana dashboard).

Ability to process content that is behind a private endpoint (URL,repo,etc.)

Not sure what exactly we mean by this or how to handle it.

Run CI against multiple versions of Go

Currently we only test against 1.12. Do we want to set up a matrix of go versions that we test against? If so -- how many versions? And where do we want our starting point to be?

Ability to fetch data from resources in the cluster to be used later (action: get)

support pre/post hooks to for example “post-process” aspects like service/application configuration and “pre-process” waiting for resources to be available

Implement a default inventory for simple use cases.

In order to lower the barrier, Dash should be able to run against an embedded default inventory such that simple repositories with a predictable directory structure could run without its own inventory file.
(see below for proposed default values)

verison: 3.0
resource_groups:
  - name: Default Resources
    resources:
    - name: Raw Manifests
      file: manifests/
    - name: Helm Templates
      template: helm/
      type: helm
    - name: OpenShift Templates
      template: openshift-templates/
      params: openshift-template-params/

Develop a more thorough quickstart for the README

We need a better basic walkthrough of using dash, and building up your first dash inventory.