-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify first sentence of each principle, for easy memorization #9
Conversation
Signed-off-by: Dan Garfield <dan@todaywasawesome.com> The "Use" is repetitive but declarative. They can be taken as axioms this way instead of a descriptor of a longer principle beneath. I think the principle should be a short line and the additional text should clarify and expand the principle.
PRINCIPLES.md
Outdated
@@ -10,20 +10,20 @@ These principles were derived from modern software operations but are rooted in | |||
|
|||
## Principles | |||
|
|||
1. **The principle of declarative desired state** | |||
1. **Use declarative infrastructure** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since "infrastructure" can be seen in the context of physical infrastructure. I would explore different word for this.
"Use declarative pattern" or or "approach" or "model"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it's just "Use Declarative State" or "Define State Declaratively"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated
An alternative could be: The Principles describe how your application should be run using GitOps:
|
Signed-off-by: Dan Garfield <dan@todaywasawesome.com>
|
||
A system managed by GitOps must have its _Desired State_ expressed declaratively as data in a format writable and readable by both humans and machines. | ||
|
||
2. **The principle of immutable desired state versions** | ||
2. **Use immutable, versioned storage** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about "Use immutable, versioned declaration" (to map to principle 4)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe "Store declarations in an immutable version control system"
It's long but I think the weakness of what I have in the PR is it sounds almost like a recommendation about what kind of storage your running infra should use which doesn't make sense.
This rephrasing feels like it emphasizes the declaration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the main point is to remove the redundant "The principle of" from every one-line principle summary. After having said these out loud to a number of people now, I agree that feels repetitive. Here they are now:
Current
GitOps Principles
- The principle of declarative desired state
- The principle of immutable desired state versions
- The principle of continuous state reconciliation
- The principle of operations through declaration
Option A 🤷
Doing this and nothing else would result in:
GitOps Principles
- Declarative desired state
- Immutable desired state versions
- Continuous state reconciliation
- Operations through declaration
Option B 😸
To format these as axioms, they should be statements. Something like:
GitOps Principles
- A system's desired state must be declarative
- Declarations must be stored as immutable versions
- State reconciliation must be continuous
- All operations should be through declaration
Option C 🤔
Alternatively we discussed that these could be formatted as commands. For example:
GitOps Principles
A system managed by GitOps must:
- Declare desired state
- Store declarations as immutable versions
- Continuously reconcile actual state
- Only operate on the system through declaration
Personally I like Option B above. However if it's too contentious I think option A would be a fine, simple way to remove the redundancy without further changes.
Thanks for kicking this off @todaywasawesome and for summarizing @scottrigby. I agree with you Scott, I like Option B. I believe the principles offer most value when they are prescriptive. I guess an Option B.1 (oh no) would be to swap "must" and "should" to "is/are" e.g.
Not passionate about the wording here, but the idea might be something that makes Option B feel less "spec" and more "principle"? |
+1 for Axioms. I want to put it on a poster. 😄
…On Tue, Jun 22, 2021, 7:09 AM Jesse Butler ***@***.***> wrote:
Thanks for kicking this off @todaywasawesome
<https://github.com/todaywasawesome> and for summarizing @scottrigby
<https://github.com/scottrigby>.
I agree with you Scott, I like Option B. I believe the principles offer
most value when they are prescriptive. I guess an Option B.1 (oh no) would
be to swap "must" and "should" to "is/are"
e.g.
1. A system's desired state is declarative
2. Declarations are stored as immutable versions
3. State reconciliation is continuous
4. All operations are initiated through declaration mutation
Not passionate about the wording here, but the idea might be something
that makes Option B feel less "spec" and more "principle"?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#9 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA5L5LDUR23JQIIPS5SUYY3TUCKRNANCNFSM462CTAOA>
.
|
Signed-off-by: Bob Bell <375968+rjbell4@users.noreply.github.com>
What about combining both: the list #9 (comment) and Option B #9 (review) (with some #9 (comment)) Into something like this:
|
I too like Option B, as well as the combination that @williamcaban suggests. The way I think of it, anything that would simplify the wording in the titles of the principles is great. All of these suggestions absolutely do that. |
To clarify my earlier comment #9 (comment) It is about providing a 1-2-3 condensable version of the principles. word > one-liner > full text so it can be represented in various ways/format during communications & presentations. Putting everything together:
|
Correct typo in principle 3
Initial work toward #13 |
Superseded by #14 |
Signed-off-by: Dan Garfield dan@todaywasawesome.com
The "Use" is repetitive but declarative. They can be taken as axioms this way instead of a descriptor of a longer principle beneath. I think the principle should be a short line and the additional text should clarify and expand the principle.