Hacker News new | ask | show | jobs
by mleonhard 1966 days ago
> opstrace create -c CONFIG_FILE_PATH PROVIDER CLUSTER_NAME

> opstrace destroy PROVIDER CLUSTER_NAME

> opstrace list PROVIDER

I want to keep cluster config in source control, track deployment changes in code reviews, and automate deployments. Do you have any plans to add an 'apply' command to support this?

$ opstrace apply -c CONFIG_FILE_PATH [--dry-run] PROVIDER CLUSTER_NAME
1 comments
jgehrcke 1966 days ago
Hey! JP from Opstrace here. Thanks for reading through things and for sharing your thoughts. The quick reply is that we still have to introduce a proper cluster config diff and mutation design.

An `apply` command might look innocent on the surface. But. Upgrades (including config changes) are hard. Super hard. If it's helping a bit: the entire current Opstrace team has dealt with super challenging platform upgrade scenarios in the most demanding customer environments in the past years. We try to not underestimate this challenge :).

We're super fast moving right now and didn't want to bother with in-place config changes (as you can imagine, we wouldn't really be able to provide solid guarantees around that). We'll work on that and make it nice when the time is right, and when we feel like we can can actually provide guarantees.

link
mleonhard 1964 days ago
Yes, `apply` is hard. It's just as hard as deploying, maintaining, and turning down a service. When adding an `apply` command to a devops tool, the tool authors must think through the entire lifecycle of their service in the user's workflow and make it work well.

The tool creators are the ones with the knowledge to figure these things out. If they don't provide `apply`, then users must research and experiment and learn by making mistakes. This is a colossal waste of effort. Users end up with brittle poorly-documented scripts to do all the things that `apply` would do. These scripts cause ongoing waste of engineering effort, customer frustration from downtime, and lost business growth and revenue.

I spent several weeks making `apply` commands for InfluxDB [0] and Grafana. This proved extremely difficult for Grafana because of deficiencies in its API. Both InfluxDB and Grafana need some work to make them fit into a modern infrastructure-as-code ops environment. Grafana's cofounder and product lead were not interested in my feedback [1] [2].

[0] https://github.com/cozydate/influxdb-apply

[1] https://news.ycombinator.com/item?id=23136582

[2] https://news.ycombinator.com/item?id=23233468

link