docs(operations): remove outdated instructions on refreshing facts cache for nodes

[farshadasadpour]

What type of PR is this?
/kind cleanup
/kind documentation

What this PR does / why we need it:

Which issue(s) this PR fixes:

Fixes #12100

Special notes for your reviewer:

The current documentation advises users to run facts.yml separately to refresh the facts cache before using the --limit option with scale.yml. However, this step is unnecessary because scale.yml already includes facts.yml as part of its execution.

Specifically:

• In scale.yml, line 5 explicitly imports facts.yml Gather facts :

  - name: Gather facts
    import_playbook: facts.yml  
  

This ensures that the facts cache is refreshed for all nodes automatically when running scale.yml, even if the --limit option is used.

By removing this redundant step from the documentation, we can simplify the instructions and prevent confusion for users, ensuring the documentation reflects the actual behavior of scale.yml.

Does this PR introduce a user-facing change?:

None

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: farshadasadpour
Once this PR has been reviewed and has the lgtm label, please assign ant31 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Hi @farshadasadpour. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[tico88612]

/label ci-short
/ok-to-test

[VannTen]

This ensures that the facts cache is refreshed for all nodes automatically when running scale.yml, even if the --limit option is used

I'm not sure what make you say that. Unless something has changed recently, you do need to run an "unlimited" facts.yml before using scale.yml (or any of the other playbooks) with --limit, because the no_proxy variable is computed from the cached facts of all hosts. And the setup tasks in facts.yml respect --limit, so they can't gather facts from host which are excluded.

[VannTen]

/hold

[farshadasadpour]

Hi @VannTen

Thank you for pointing this out! I now understand your reasoning. The recommendation to run facts.yml globally, without --limit, makes sense because certain global variables like no_proxy depend on the cached facts of all hosts in the inventory. Running facts.yml with --limit only gathers facts for the specified subset, leaving other hosts excluded. This can lead to incomplete or missing data for variables that require cluster-wide information.

I’ll revisit my assumption and look deeper into this behavior to confirm how the cached facts impact subsequent playbooks like scale.yml. Thanks again for clarifying this!

[farshadasadpour]

@VannTen

I’ve identified two possible approaches to resolve the issue:

1. Edit the Documentation: Update it to clarify the path to facts.yml, explicitly referencing playbooks/facts.yml. For example:

Before using `--limit`, run the playbook `playbooks/facts.yml` without the limit to refresh the facts cache for all nodes.

2. Add facts.yml to the Root: Place a copy of facts.yml in the root directory to simplify access for users, allowing them to run it directly as facts.yml without navigating subdirectories like playbooks/. like other files.

Which option do you think is better? Personally, I lean toward option 1 (clarifying documentation) because it avoids changing the repository structure, but I’m open to your thoughts!

[vdveldet]

I would go for option 2, sinds that is the same for the other playbooks as well.

[VannTen]

Thanks for the work, we've gone with #12177 instead