Open nestorsalceda opened 5 years ago
@nestorsalceda Good suggestion!
I'd render the helm chart to produce a set of manifests and include it in the repo.
An example using a Subscription to a catalog like OperatorHub.io provides at https://operatorhub.io/install/falco.yaml may be appropriate here.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
In this moment, the operator is deployed using the
helm tiller
plugin. Not all people has helm or neither the tiller plugin installed.Is there another user experience deploying operators like:
$ kubectl create -f https://coreos.com/operators/etcd/latest/deployment.yaml
$ kubectl create -f https://coreos.com/operators/prometheus/latest/prometheus-operator.yaml
The point is that the less external dependencies we have, the better for get more people involved using and contributing to Falco, so I think that using just
kubectl
like etcd or prometheus would be awesome.Thanks!