Script to generate longhorn.yaml with version replacement

[roger-ryao]

Which issue(s) this PR fixes:

longhorn/longhorn#9512

What this PR does / why we need it:

The script is provided that can:

• Take arguments for the old version, new version, and Longhorn version.
• Download the corresponding longhorn.yaml file.
• Perform a search-and-replace operation to update all relevant image tags.
• Save the final file with a filename based on the major version number.

> ./update_LH_ver_with_download.sh 

Usage: ./update_LH_ver_with_download.sh <old_version> <new_version> <longhorn_version>

Arguments:
  <old_version>       The version of Longhorn images to be replaced (e.g., v1.6.3, v1.7.1).
  <new_version>       The new version of Longhorn images to use (e.g., v1.6.3-dev-20240922, v1.7.x-head).
  <longhorn_version>  The branch or tag from which to download the Longhorn YAML file.

  Examples:

    # For downloading longhorn.yaml from the v1.6.x branch
    ./update_LH_ver_with_download.sh v1.6.3 v1.6.3-dev-20240922 v1.6.x

    # For downloading longhorn.yaml from the v1.7.x branch
    ./update_LH_ver_with_download.sh v1.7.1 v1.7.x-head v1.7.x

    # For downloading longhorn.yaml from the master branch
    ./update_LH_ver_with_download.sh master-head v1.8.0-dev-20240922 master

Special notes for your reviewer:

Additional documentation or context

[yangchiu]

Why can't we just use https://raw.githubusercontent.com/longhorn/longhorn/refs/tags/v1.8.0-dev-20240922/deploy/longhorn.yaml?

@derekbit, why are the Longhorn component versions in the sprint release v1.8.0-dev-20240922 set to master-head instead of being fixed to v1.8.0-dev-20240922? Is this intentional?

[roger-ryao]

Why can't we just use https://raw.githubusercontent.com/longhorn/longhorn/refs/tags/v1.8.0-dev-20240922/deploy/longhorn.yaml?

If you hadn't asked this question, I don't know that we actually have a sprint release YAML file link available.

[yangchiu]

@derekbit, why are the Longhorn component versions in the sprint release v1.8.0-dev-20240922 set to master-head instead of being fixed to v1.8.0-dev-20240922? Is this intentional?

Need @derekbit to confirm if the sprint release longhorn.yaml is correct.

[roger-ryao]

@derekbit, why are the Longhorn component versions in the sprint release v1.8.0-dev-20240922 set to master-head instead of being fixed to v1.8.0-dev-20240922? Is this intentional?

Need @derekbit to confirm if the sprint release longhorn.yaml is correct.

After the QA meeting, we created the issue #9529. This script not only provides a workaround but also helps us generate the YAML file for v1.7.x-head or v1.6.x-head.

[yangchiu]

@derekbit, why are the Longhorn component versions in the sprint release v1.8.0-dev-20240922 set to master-head instead of being fixed to v1.8.0-dev-20240922? Is this intentional?

Need @derekbit to confirm if the sprint release longhorn.yaml is correct.

After the QA meeting, we created the issue #9529. This script not only provides a workaround but also helps us generate the YAML file for v1.7.x-head or v1.6.x-head.

@derekbit I think longhorn/longhorn#9529 should be prioritized since it makes sprint release ineffective.

Once longhorn/longhorn#9529 is resolved, this PR will become redundant. @roger-ryao Feel free to close this PR after longhorn/longhorn#9529 is resolved.