chore(docs): zarf principles draft #3562
Conversation
Signed-off-by: Brandt Keller <[email protected]>
✅ Deploy Preview for zarf-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Codecov ReportAll modified and coverable lines are covered by tests ✅ 🚀 New features to boost your workflow:
|
| Zarf operates in Kubernetes clusters but does not attempt to replace existing Kubernetes tooling. Instead, Zarf should: | ||
| - Focus on enabling package management and deployment in airgapped clusters. | ||
| - Complement, rather than compete with, Kubernetes-native solutions (e.g., Helm, Kustomize, and Operator patterns). | ||
| - Facilitate cluster initialization and ongoing software management without enforcing opinionated infrastructure choices. |
There was a problem hiding this comment.
It may be worth calling out that in complementing the K8s environment it should also "fit in" from a user and dev experience perspective - i.e. Zarf shouldn't invent its own workflows unless that workflow is just something that doesn't exist (Zarf Values <> Zarf Variables would be a good example there).
| Zarf should remain simple to use and operationalize, with considerations such as: | ||
| - Clear and concise configuration files that reduce complexity. | ||
| - A user-friendly CLI that abstracts away unnecessary details while allowing expert-level control when needed. | ||
| - Automation and scripting capabilities that streamline usage in constrained environments. |
There was a problem hiding this comment.
Developer simplicity I think is also key here - there are special things like the zarf dev find-images commands that really help developers build up their packages and gather resources.
| ## 6. Compatibility and Extensibility | ||
| Zarf should be flexible enough to work in various environments while maintaining its core mission. This means: | ||
| - Supporting multiple architectures and operating systems where feasible. | ||
| - Allowing extensibility through custom package configurations and integrations. |
There was a problem hiding this comment.
Worth calling out its use as a library explicitly here? (since "integrations" could be many things and some of them we may not prefer (i.e. a python script that generates Zarf packages and drives Zarf's CLI would be an "integration" but IMO that would be treated differently from a Go CLI importing Zarf as a library)
| - A user-friendly CLI that abstracts away unnecessary details while allowing expert-level control when needed. | ||
| - Automation and scripting capabilities that streamline usage in constrained environments. | ||
|
|
||
| ## 6. Compatibility and Extensibility |
There was a problem hiding this comment.
It may be worth calling out specific expectations around stability of interfaces - i.e. what is "stable" in the CLI (probably a lot but not zarf internal?) or what is exposed in the library
Description
WIP: drafting some principles for discussion.
Zarf needs objective criteria for reviewing new or modified behavior when submitted from any entity.
This will better allow capability review without the potential for interpreting the decision as subjective.
Related Issue
Fixes #3552
Relates to #
Checklist before merging