Date
1 - 1 of 1
Operator WG Document Structure
Thomas Schuetz
Hello!
In yesterday's SIG Meeting we discussed about how to proceed with the Operator WG and found out that it would be useful to find out what the goal of the document is, but also to clean up the working document a bit. In my opinion it would be very nice if there would be a document which could give people a short overview what an operator is, when it could be useful to use an operator and how typical use cases or best practices (without re-inventing the wheel) could look like.
As a proposal, the structure of such an document could look like:
Any opinions, thoughts and discussions would be very welcome.
- Thomas Schuetz
In yesterday's SIG Meeting we discussed about how to proceed with the Operator WG and found out that it would be useful to find out what the goal of the document is, but also to clean up the working document a bit. In my opinion it would be very nice if there would be a document which could give people a short overview what an operator is, when it could be useful to use an operator and how typical use cases or best practices (without re-inventing the wheel) could look like.
As a proposal, the structure of such an document could look like:
- Introduction / Problem Definition
- Objectives / Topical Restrictions
- Related Technologies (e.g. Helm, CNAB, OAM and the distinction to operators)
- Fundamentals (What is an Operator? When would it make sense to use an operator? When could it be an overkill?)
- Best Practices (e.g. Idempotency, How to deal with external dependencies)?
- Typical Use Cases for Operators (Provide "good" examples from CNCF Projects)
- Conclusion
Any opinions, thoughts and discussions would be very welcome.
- Thomas Schuetz