Conversation
hekike
added
kind/feature
| c.Server.DisableNamespaceCreate = true | ||
| c.Server.DisableNamespaceDelete = true | ||
| c.Server.DisableMeterCreate = true | ||
| c.Server.DisableMeterDelete = true |
There was a problem hiding this comment.
This is not gonna work:
- First of all, Validate shouldn't change the state
- Secondly, the receiver is not a pointer which means any change within this function would be lost.
A better pattern to do config processing is creating a Process function and calling that prior to validate:
func (c *configuration) Process() {
// ...
}Call this function in main before validate.
| DisableNamespaceCreate bool | ||
| DisableNamespaceDelete bool | ||
| DisableMeterCreate bool | ||
| DisableMeterDelete bool |
There was a problem hiding this comment.
Let's leave these here for now, but I think logically, these belong under namespace and meter specific configuration.
The config controls the feature, not the HTTP layer. I'm okay with merging this PR as it is, but I will probably send another PR refactoring this a bit.
| ### Config Mode | ||
|
|
||
| Config mode is the default and recommended mode in OpenMeter. In this mode you can define meters via the `config.yaml`. | ||
| As the state is defined in the config, namespace and meter management HTTP endpoints are disabled. |
There was a problem hiding this comment.
Since namespaces are not stored anyway, does this actually make sense?
|
|
||
| ### Stateless Mode | ||
|
|
||
| You can enable stateless mode via `stateless: true` in the config. In this mode meters defined in the `config.yaml` are ignored. In stateless mode you can define namespaces and meters via the HTTP API but these states are not persisted and after restarting OpenMeter they will be lost. Resources created by OpenMeter like Kafka topics, KSQL tables etc. will may remain persisted. |
There was a problem hiding this comment.
Again, namespaces are not stored anyway (but do not get lost either). Does it make sense to call that out this way?
2 participants
This PR adds: