ProtoConfig 1.0: Open Standard for using, defining, and consuming software configuration input in a unified way.
The ProtoConfig 1.0
is an open, language agnostic specification that describes a process of using, defining, and consuming software configuration input in a unified way.
Like OpenAPI but for Configuration!
Designed to support all popular configuration patterns: Cloud Native Configuration as a Code
, robust command line interfaces (CLI), static or dynamic configurability as well as remote configuration APIs.
The ProtoConfig 1.0
standardises application configuration, by describing the process as follows:
Configuration Proto Definition
, that defines what exactly options application has.stdin
, CLI flag or HTTP API, etc).ProtoConfig
allows generation extensibility, so such definition can be also used to generate documentation, --help
, man
, custom types, or even whole CLI flag & args parsing code. Options are unlimited!ProtoConfig
convention, a human or program can now configure the application either by specifying JSON manually or by generating (again) data structure from Configuration Proto Definition
in the programming language they want. Such struct/class is typed (if a language is typed), have a valid format, have help commentaries and can be encoded to protobuf
supported format and passed to the configurable
application!ProtoConfig 1.0
standard specifies that every ProtoConfig 1.0
compatible application accepts encoded protobuf
in proto or JSON format as the way of configuring itself. Either as the only way or in addition to other conventions (e.g args and flags).
Configure software in a way that is:
protobuf
in almost any programming language, thanks to the wide plugin ecosystem. Additionally, you can generate a full CLI flag paring code or even documentation(!). It also means the smallest, possible impact in the event of application upgrade or modification. Type, Default, or even Help changed can be easily tracked in any language.
protobuf
. https://github.com/envoyproxy/protoc-gen-validate
protobuf
guarantee and safety checkers like buf check breaking
kingpinv2
Go package and its extensions)
See "Configuration in 2021 is still broken" blog post (TBD).
See ./specification#principles.
See ./specification#why-protocol-buffers
See example in Go.
If you are not familiar with Go, this is still a useful example, as the flow and pattern will be similar to any language.
Item | What | Status |
---|---|---|
proto/protoconfig/v1/extensions.proto |
Proto Config Extensions Format 1.0 | Alpha |
proto/examples/helloworld/v1/helloworld.proto |
Example Configuration Proto Definitions (CPD) | Alpha |
go/ |
Go module with (optional) Proto Config Extensions Format 1.0 bindings | Alpha |
go/protoc-gen-go-protoconfig |
Go module with (optional) protogen go plugin supporting Proto Config Extensions Format 1.0 Go language | Alpha |
go/examples |
Go module with (optional) protogen go plugin supporting Proto Config Extensions Format 1.0 Go language | Alpha |
Any help wanted. Do you have an idea, want to help, don't know how to start helping?
Put an issue on this repo, create PR or ping us on the CNCF Slack (@bwplotka
, @brancz
)! 🤗
YANG
(some sort of XML
) instead of more modern protobuf
which was designed for code generation and IDL.ProtoConfig
does not specify how to
do dynamic configuration, leaving that to extensions that can be added to specification itself (e.g language specific generator that generates lib for dynamic reloading).ProtoConfig
does not need to care about status codes, HTTP specifics or actually even OS/Process details. ProtoConfig
can be appliedHelp wanted!
protobuf
are hard to use. Standard should specify some solution when Encoded Configuration Message
is larger than Megabytes.