Skip to content
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

docs: clarify + improve Workflow Restrictions page #11807

Merged

Conversation

agilgur5
Copy link
Contributor

@agilgur5 agilgur5 commented Sep 12, 2023

Motivation

A number of people, including me, have been confused by the ambiguous language on this page.

  • This popped up recently on Slack, so I dove into the codebase to verify the behavior in order to be able to clarify the docs

Modifications

  • clarify what Secure means by "between operations" and "enforce"

    • see current Workflow Restrictions feature code, specifically, MustNotChangeSpec function
    • if a Workflow MustNotChangeSpec, then it will be marked as errored if its underlying WorkflowTemplate changes during execution
      • marking the Workflow as errored stops it
  • clarify that Secure is a superset of Strict by rewording to say "Same as Strict plus [...]"

    • MustUseRference checks for either Secure or Strict
    • remove duplicate language on arbitrary Workflows that was uniquely worded and made it seem like Secure acted differently (it does not other than the one additional feature)
    • change the example to use Strict because it only uses that feature and does not specify a reason to use Secure
      • makes it less confusing about that the overlap. Secure is a strict superset
      • also add a colon after the example intro
  • clarify the word "limiting" by instead saying "disallowing"

    • with templateRestrictions, you must use a workflowTemplateRef with no exceptions
  • use simpler and more direct language, per k8s style guide

  • use active voice, per k8s style guide

  • consistently refer to the reader as "you", per k8s style guide

    • previously the doc referred to the admin as you initially, but then refers to the admin again in third-person
    • also consistently use "users" instead of "users" and then "operators", which made it very ambiguous who the subject was

Verification

n/a

- clarify what `Secure` means by "between operations" and "enforce"
  - a number of people, including me, have been confused by the ambiguous language before
  - see current Workflow Restrictions feature code, specifically, [`MustNotChangeSpec` function](https://github.com/argoproj/argo-workflows/blob/6399ac70619ff037793b773d44131c7a1f9e7fb6/config/config.go#L292)
  - if a Workflow `MustNotChangeSpec`, then it will be [marked as errored](https://github.com/argoproj/argo-workflows/blob/bcb5a3e0e984727947ae132ba712c27cc0ec82c2/workflow/controller/operator.go#L3844) if its underlying WorkflowTemplate changes during execution
    - marking the Workflow as errored [stops it](https://github.com/argoproj/argo-workflows/blob/2f5af0ab21463aeb250aa6f1a31cca522aec7408/workflow/controller/operator.go#L2239)

- clarify that `Secure` is a superset of `Strict` by rewording to say "Same as `Strict` _plus_ [...]"
  - [`MustUseRference`](https://github.com/argoproj/argo-workflows/blob/bcb5a3e0e984727947ae132ba712c27cc0ec82c2/config/config.go#L285) checks for _either_ `Secure` or `Strict`
  - remove duplicate language on arbitrary Workflows that was uniquely worded and made it seem like `Secure` acted differently (it does not other than the one additional feature)
  - change the example to use `Strict` because it only uses that feature and does not specify a reason to use `Secure`
    - makes it less confusing about that the overlap. `Secure` is a strict superset

- clarify the word "limiting" by instead saying "disallowing"
  - with `templateRestrictions`, you _must_ use a `workflowTemplateRef` with _no_ exceptions

- use simpler and more direct language, per [k8s style guide](https://kubernetes.io/docs/contribute/style/style-guide/#use-simple-and-direct-language)
- use active voice, [per k8s style guide](https://kubernetes.io/docs/contribute/style/style-guide/#use-active-voice)
- consistently refer to the reader as "you", [per k8s style guide](https://kubernetes.io/docs/contribute/style/style-guide/#address-the-reader-as-you)
  - previously the doc referred to the admin as you initially, but then refers to the admin again in third-person
  - also consistently use "users" instead of "users" and then "operators", which made it very ambiguous who the subject was

Signed-off-by: Anton Gilgur <[email protected]>
@agilgur5 agilgur5 added the area/docs Incorrect, missing, or mistakes in docs label Sep 12, 2023
Signed-off-by: Anton Gilgur <[email protected]>
- surprised these weren't already in there

Signed-off-by: Anton Gilgur <[email protected]>
@agilgur5
Copy link
Contributor Author

Unrelated unit test failure. If that's a flake, I actually haven't seen that one before -- might be an actual race error, but not sure as the test diff is really hard to read.

Will need a CI retry 😕

@agilgur5
Copy link
Contributor Author

Unit test failure should have been fixed by #11816, so merged master

@terrytangyuan terrytangyuan enabled auto-merge (squash) October 20, 2023 02:05
@agilgur5
Copy link
Contributor Author

ah I need to merge master for the new required composite E2E check from #12006 to run

@terrytangyuan terrytangyuan merged commit b38c6fd into argoproj:master Oct 20, 2023
16 checks passed
@agilgur5 agilgur5 deleted the docs-clarify-workflow-restrictions branch October 20, 2023 02:40
agilgur5 added a commit that referenced this pull request May 4, 2024
Signed-off-by: Anton Gilgur <[email protected]>
(cherry picked from commit b38c6fd)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/docs Incorrect, missing, or mistakes in docs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants