#30 support yaml for desired state files.

README.md

@@ -10,7 +10,8 @@ Helmsman is a Helm Charts (k8s applications) as Code tool which allows you to au
 
 # How does it work?
 
-Helmsman uses a simple declarative [TOML](https://github.com/toml-lang/toml) file to allow you to describe a desired state for your k8s applications as in the [example file](https://github.com/Praqma/helmsman/blob/master/example.toml).
+Helmsman uses a simple declarative [TOML](https://github.com/toml-lang/toml) file to allow you to describe a desired state for your k8s applications as in the [example toml file](https://github.com/Praqma/helmsman/blob/master/example.toml).
+Alternatively YAML declaration is also acceptable [example yaml file](https://github.com/Praqma/helmsman/blob/master/example.yaml).
 
 The desired state file (DSF) follows the [desired state specification](https://github.com/Praqma/helmsman/blob/master/docs/desired_state_specification.md).
 

dockerfile/README.md

@@ -11,7 +11,7 @@ docker run -v $(pwd):/tmp --rm -it \
 -e AWS_DEFAULT_REGION=<aws_region> \
 -e AWS_SECRET_ACCESS_KEY=<acess_key> \
 praqma/helmsman:v0.1.2 \
-helmsman -debug -apply -f <your_desired_state_file.toml>
+helmsman -debug -apply -f <your_desired_state_file>.<toml|yaml>
 ```
 
 Check the different image tags on [Dockerhub](https://hub.docker.com/r/praqma/helmsman/)

dockerfile/dockerfile

@@ -1,6 +1,7 @@
 FROM golang:1.9 as builder
 WORKDIR /go/src/
 RUN go get github.com/BurntSushi/toml
+RUN go get gopkg.in/yaml.v2
 RUN git clone https://github.com/Praqma/helmsman.git 
 RUN go get github.com/Praqma/helmsman/gcs 
 RUN go get github.com/Praqma/helmsman/aws 

docs/deplyment_strategies.md

@@ -12,7 +12,7 @@ Suppose you are deploying 3rd party charts (e.g. Jenkins, Jira ... etc.) in your
 
 You can test 3rd party charts in designated namespaces (e.g, staging) within the same production cluster. This also can be defined in the same desired state file. Below is an example of a desired state file for deploying 3rd party apps in production and staging namespaces:  
 
-```
+```toml
 [metadata]
 org = "example"
 
@@ -64,6 +64,55 @@ incubator = "http://storage.googleapis.com/kubernetes-charts-incubator"
 
 ```
 
+```yaml
+metadata:
+  org: "example"
+
+# using a minikube cluster
+settings:
+  kubeContext: "minikube"
+
+namespaces:
+  staging:
+    protected: false
+  production:
+    protected: true
+
+helmRepos:
+  stable: "https://kubernetes-charts.storage.googleapis.com"
+  incubator: "http://storage.googleapis.com/kubernetes-charts-incubator"
+
+apps:
+  jenkins:
+    name: "jenkins-prod" # should be unique across all apps
+    description: "production jenkins"
+    namespace: "production"
+    enabled: true
+    chart: "stable/jenkins"
+    version: "0.9.1" # chart version
+    valuesFile: "../my-jenkins-production-values.yaml"
+
+  artifactory:
+    name: "artifactory-prod" # should be unique across all apps
+    description: "production artifactory"
+    namespace: "production"
+    enabled: true
+    chart: "stable/artifactory"
+    version: "6.2.0" # chart version
+    valuesFile: "../my-artificatory-production-values.yaml"
+
+  # the jenkins release below is being tested in the staging namespace
+  jenkins-test:
+    name: "jenkins-test" # should be unique across all apps
+    description: "test release of jenkins, testing xyz feature"
+    namespace: "staging"
+    enabled: true
+    chart: "stable/jenkins"
+    version: "0.9.1" # chart version
+    valuesFile: "../my-jenkins-testing-values.yaml"
+
+```
+
 You can split the desired state file into multiple files if your deployment pipelines requires that, but it is important to read the notes below on using multiple desired state files with one cluster.
 
 ## Working with multiple clusters

docs/desired_state_specification.md

@@ -4,7 +4,7 @@ version: v1.2.0
 
 # Helmsman desired state specification
 
-This document describes the specification for how to write your Helm charts desired state file. The desired state file consists of:
+This document describes the specification for how to write your Helm charts desired state file. This can be either toml or yaml file. The desired state file consists of:
 
 - [Metadata](#metadata) [Optional] -- metadata for any human reader of the desired state file.
 - [Certificates](#certificates) [Optional] -- only needed when you want Helmsman to connect kubectl to your cluster for you.
@@ -24,12 +24,18 @@ Options:
 
 Example: 
 
-```
+```toml
 [metadata]
 scope = "cluster foo"
 maintainer = "k8s-admin"
 ```
 
+```yaml
+metadata:
+  scope: "cluster foo"
+  maintainer: "k8s-admin"
+```
+
 ## Certificates
 
 Optional : Yes, only needed if you want Helmsman to connect kubectl to your cluster for you.
@@ -47,14 +53,22 @@ Options:
 
 Example: 
 
-```
+```toml
 [certificates]
 caCrt = "s3://myS3bucket/mydir/ca.crt" 
 caKey = "gs://myGCSbucket/ca.key" 
 caClient ="../path/to/my/local/client-certificate.crt"
 #caClient = "$CA_CLIENT"
 ```
 
+```yaml
+certificates:
+  caCrt: "s3://myS3bucket/mydir/ca.crt"
+  caKey: "gs://myGCSbucket/ca.key"
+  caClient: "../path/to/my/local/client-certificate.crt"
+  #caClient: "$CA_CLIENT"
+```
+
 ## Settings
 
 Optional : No.
@@ -76,7 +90,7 @@ The following options can be skipped if your kubectl context is already created
 
 Example: 
 
-```
+```toml
 [settings]
 kubeContext = "minikube" 
 # username = "admin"
@@ -87,6 +101,17 @@ kubeContext = "minikube"
 # storageBackend = "secret"
 ```
 
+```yaml
+settings:
+  kubeContext = "minikube"
+  #username: "admin"
+  #password: "$K8S_PASSWORD"
+  #clusterURI: "https://192.168.99.100:8443"
+  ##clusterURI: "$K8S_URI"
+  #serviceAccount: "my-service-account"
+  #storageBackend: "secret"
+```
+
 ## Namespaces
 
 Optional : No.
@@ -111,7 +136,7 @@ Options:
 
 Example: 
 
-```
+```toml
 [namespaces]
 [namespaces.staging]
 [namespaces.dev]
@@ -127,6 +152,22 @@ clientCert = "gs://mybucket/mydir/helm.cert.pem"
 clientKey = "s3://mybucket/mydir/helm.key.pem"
 ```
 
+```yaml
+namespaces:
+  staging:
+  dev:
+    protected: false
+  production:
+    protected: true
+    installTiller: true
+    tillerServiceAccount: "tiller-production"
+    caCert: "secrets/ca.cert.pem"
+    tillerCert: "secrets/tiller.cert.pem"
+    tillerKey: "$TILLER_KEY" # where TILLER_KEY=secrets/tiller.key.pem
+    clientCert: "gs://mybucket/mydir/helm.cert.pem"
+    clientKey: "s3://mybucket/mydir/helm.key.pem"
+```
+
 ## Helm Repos
 
 Optional : No.
@@ -146,14 +187,22 @@ Options:
 
 Example: 
 
-```
+```toml
 [helmRepos]
 stable = "https://kubernetes-charts.storage.googleapis.com"
 incubator = "http://storage.googleapis.com/kubernetes-charts-incubator"
 myS3repo = "s3://my-S3-private-repo/charts"
 myGCSrepo = "gs://my-GCS-private-repo/charts"
 ```
 
+```yaml
+helmRepos:
+  stable: "https://kubernetes-charts.storage.googleapis.com"
+  incubator: "http://storage.googleapis.com/kubernetes-charts-incubator"
+  myS3repo: "s3://my-S3-private-repo/charts"
+  myGCSrepo: "gs://my-GCS-private-repo/charts"
+```
+
 ## Apps
 
 Optional : Yes.
@@ -182,7 +231,7 @@ Example:
 
 > Whitespace does not matter in TOML files. You could use whatever indentation style you prefer for readability.
 
-```
+```toml
 [apps]
 
     [apps.jenkins]
@@ -204,3 +253,23 @@ Example:
 
 ```
 
+```yaml
+apps:
+  jenkins:
+    name: "jenkins"
+    description: "jenkins"
+    namespace: "staging"
+    enabled: true
+    chart: "stable/jenkins"
+    version: "0.9.0"
+    valuesFile: ""
+    purge: false
+    test: true
+    protected: false
+    wait: true
+    priority: -3
+    set:
+      secret1: "$SECRET_ENV_VAR1"
+      secret2: "$SECRET_ENV_VAR2"
+
+```

docs/how_to/define_namespaces.md

@@ -15,6 +15,15 @@ You can define namespaces to be used in your cluster. If they don't exist, Helms
   protected = true # default is false
 
 ...
+```
+
+```yaml
+
+namespaces:
+  staging:
+  production:
+    protected: true # default is false
+
 
 ```
 
@@ -35,6 +44,19 @@ As of `v1.2.0-rc`, you can instruct Helmsman to deploy Tiller into specific name
   clientKey = "s3://mybucket/mydir/helm.key.pem"
 ```
 
+```yaml
+namespaces:
+  production:
+    protected: true
+    installTiller: true
+    tillerServiceAccount: "tiller-production"
+    caCert: "secrets/ca.cert.pem"
+    tillerCert: "secrets/tiller.cert.pem"
+    tillerKey: "$TILLER_KEY" # where TILLER_KEY=secrets/tiller.key.pem
+    clientCert: "gs://mybucket/mydir/helm.cert.pem"
+    clientKey: "s3://mybucket/mydir/helm.key.pem"
+```
+
 You can then tell Helmsman to deploy specific releases in a specific namespace:
 
 ```toml
@@ -56,6 +78,23 @@ You can then tell Helmsman to deploy specific releases in a specific namespace:
 
 ``` 
 
+```yaml
+...
+apps:
+  jenkins:
+    name: "jenkins"
+    description: "jenkins"
+    namespace: "production" # pointing to the namespace defined above
+    enabled: true
+    chart: "stable/jenkins"
+    version: "0.9.1"
+    valuesFile: ""
+    purge: false
+    test: true
+
+...
+
+```
 
 In the above example, `Jenkins` will be deployed in the production namespace using the Tiller deployed in the production namespace. If the production namespace was not configured to have Tiller deployed there, Jenkins will be deployed using the Tiller in `kube-system`. 
 

docs/how_to/manipulate_apps.md

@@ -4,7 +4,7 @@ version: v1.2.0-rc
 
 # install releases 
 
-You can run helmsman with the [example.toml](https://github.com/Praqma/helmsman/blob/master/example.toml) file.
+You can run helmsman with the [example.toml](https://github.com/Praqma/helmsman/blob/master/example.toml) or [example.yaml](https://github.com/Praqma/helmsman/blob/master/example.yaml) file.
 
 ``` 
 
@@ -61,7 +61,7 @@ If you would like the release to be deleted along with its history, you can use
 
 > NOTE: purge deleting a release means you can't roll it back.
 
-```
+```toml
 ...
 [apps]
 
@@ -79,6 +79,23 @@ If you would like the release to be deleted along with its history, you can use
 ...
 ``` 
 
+```yaml
+...
+apps:
+  jenkins:
+    name: "jenkins"
+    description: "jenkins"
+    namespace: "staging"
+    enabled: false # this tells helmsman to delete it
+    chart: "stable/jenkins"
+    version: "0.9.1"
+    valuesFile: ""
+    purge: true # this means purge delete this release whenever it is required to be deleted
+    test: flase
+
+...
+```
+
 # rollback releases 
 
 Similarly, if you change `enabled` back to `true`, it will figure out that you would like to roll it back.