Apologies for not answering sooner - I didn't realise there were any comments until today! It will take me a couple of weeks but I'll setup a public Github repo with the demo code (other people have asked also)
Not sure how the helmfile operator helps to solve the bootstrapping problem, if terraform installs it? Why can’t you run the helmfile command with terraform and solve the bootstrapping this way without the need for an operator?
"The main idea behind having an operator is to have a system running constantly, looking for events to take action and maintain the desired state. For example, if the helmfile command executed by the terraform command fails, how can it be retried? Additionally, how can the argocd version be upgraded automatically? With an operator, these tasks can be easily automated."
My personal opinion is that using TF for deploying stuff into K8s clusters is an anti-pattern as you now have 2 sources of truth for the K8s cluster state: the K8s control plane and a tfstate file, so the chance of drift increases. I also don't much like the K8s related providers, i.e. the Helm, Helmfile and Kubernetes ones. I think the kubectl one is ok but it hasn't been touched for years. All that said, I did use TF to deploy my Helmfile operator into my K8s cluster (using raw manifests and the kubectl provider) as a 'one off', i.e. once the operator was installed I would never need to use TF to deploy anything else into the cluster.
![Policy as [versioned] code | Chris Nesbitt-Smith](http://i.ytimg.com/vi/yL62l-XE268/mqdefault.jpg)
![Policy as [versioned] code | Chris Nesbitt-Smith](/img/tr.png)
It would have been nice if there was a link to the code demoed
Apologies for not answering sooner - I didn't realise there were any comments until today! It will take me a couple of weeks but I'll setup a public Github repo with the demo code (other people have asked also)
@@stephenjudd9799 Would be really helpful if we could have this code, it's really well explained :)
@@stephenjudd9799 did you have any updates about it? i really need this :(
@@stephenjudd9799 Any updates about this? i really need it :(
@@stephenjudd9799 did you managed to finish the code?
Not sure how the helmfile operator helps to solve the bootstrapping problem, if terraform installs it? Why can’t you run the helmfile command with terraform and solve the bootstrapping this way without the need for an operator?
Not clear to me as well. Instead of using terraform we need to install custom operator…. But how? With tf?
"The main idea behind having an operator is to have a system running constantly, looking for events to take action and maintain the desired state. For example, if the helmfile command executed by the terraform command fails, how can it be retried? Additionally, how can the argocd version be upgraded automatically? With an operator, these tasks can be easily automated."
My personal opinion is that using TF for deploying stuff into K8s clusters is an anti-pattern as you now have 2 sources of truth for the K8s cluster state: the K8s control plane and a tfstate file, so the chance of drift increases. I also don't much like the K8s related providers, i.e. the Helm, Helmfile and Kubernetes ones. I think the kubectl one is ok but it hasn't been touched for years. All that said, I did use TF to deploy my Helmfile operator into my K8s cluster (using raw manifests and the kubectl provider) as a 'one off', i.e. once the operator was installed I would never need to use TF to deploy anything else into the cluster.
Does someone know where the code is?
Watch this space. It will take a couple of weeks but I'll put together a public repo with the demo code
@@stephenjudd9799 did you managed to finished the demo code?
@@stephenjudd9799 did you managed to finish the demo code?
@@stephenjudd9799 Thanks!
@@stephenjudd9799 Did you managed to finish the demo code?