3 ms·

We might have different target audiences of our work, but in my line configs should not require tests. Because their task is to adjust the functioning of an app

We might have different target audiences of our work, but in my line configs should not require tests. Because their task is to adjust the functioning of an application. If they all of a sudden require tests, that means (at least to me) that it's not part of the configuration anymore, but a part of the application proper and should be treated as such.

q3k 7y ago
For me the target is mostly verbose YAML configuration of existing software (which I can now emit from an in-memory object instead of templating and having to remember all the YAML quirks) and k8s manifests. Especially when I have to stamp the same piece of software multiple times in multiple deployments (environments/regions/etc). For instance: I just brought up a new Factorio game server yesterday, just by adding a single line to my jsonnet configuration machinery: https://gerrit.hackerspace.pl/c/hscloud/+/246 https://gerrit.hackerspace.pl/c/hscloud/+/246 . This in turn brought up a bunch of new k8s resources, including some persistent volumes, a deployment, and a loadbalancer service, after running a single `kubecfg update` command.
- jevgeni 7y ago
  I agree, that YAML is usually a mistake. In your scenario, it's more like provisioning of infrastructure and in that case - configuration is the code, so I can see where you are coming from. I mostly write financial software so the use case is usually closer to classical single machine applications. And in that case, I prefer simple TOML.
darkwater 7y ago
And what about "configs" like Kubernetes deployments?
- shawnz 7y ago
  You could use the Maven approach: for whatever the declarative configuration isn't powerful enough to specify, you write a plugin. That plugin can then be developed and managed just like any other software project, rather than having to bring those tools into the configuration realm.
  - rfoo 7y ago
    Wait. In this case aren't the plugin itself "code in runtime config"? edit: Now I understand that being a plugin it must have proper abstraction, but ad-hoc logic do exist.
    - shawnz 7y ago
      I guess it depends on how you look at it, but if the plugin is a self-contained module that can be managed independently from the app it's configuring, I wouldn't really say it's code that's "in" the configuration. > ... but ad-hoc logic do exist. True. I don't disagree, no tool is right for every job.
- jevgeni 7y ago
  Personally, I group these use cases under "infrastructure provisioning". The use case here is completely different - for example, you won't have a non-developer modifying the configs. So in this case, automation is a good idea.

q3k 7y ago

For me the target is mostly verbose YAML configuration of existing software (which I can now emit from an in-memory object instead of templating and having to remember all the YAML quirks) and k8s manifests. Especially when I have to stamp the same piece of software multiple times in multiple deployments (environments/regions/etc). For instance: I just brought up a new Factorio game server yesterday, just by adding a single line to my jsonnet configuration machinery: https://gerrit.hackerspace.pl/c/hscloud/+/246 https://gerrit.hackerspace.pl/c/hscloud/+/246 . This in turn brought up a bunch of new k8s resources, including some persistent volumes, a deployment, and a loadbalancer service, after running a single `kubecfg update` command.

jevgeni 7y ago
I agree, that YAML is usually a mistake. In your scenario, it's more like provisioning of infrastructure and in that case - configuration is the code, so I can see where you are coming from. I mostly write financial software so the use case is usually closer to classical single machine applications. And in that case, I prefer simple TOML.

darkwater 7y ago

And what about "configs" like Kubernetes deployments?

shawnz 7y ago
You could use the Maven approach: for whatever the declarative configuration isn't powerful enough to specify, you write a plugin. That plugin can then be developed and managed just like any other software project, rather than having to bring those tools into the configuration realm.
- rfoo 7y ago
  Wait. In this case aren't the plugin itself "code in runtime config"? edit: Now I understand that being a plugin it must have proper abstraction, but ad-hoc logic do exist.
  - shawnz 7y ago
    I guess it depends on how you look at it, but if the plugin is a self-contained module that can be managed independently from the app it's configuring, I wouldn't really say it's code that's "in" the configuration. > ... but ad-hoc logic do exist. True. I don't disagree, no tool is right for every job.
jevgeni 7y ago
Personally, I group these use cases under "infrastructure provisioning". The use case here is completely different - for example, you won't have a non-developer modifying the configs. So in this case, automation is a good idea.