Skip to content

feat: Add ability to select version of demos/stacks #310

Description

@NickLarsenNZ

Once demos are versioned per release (see sub-issue) DONE, we should be able to select which demo/stack version to install.

Suggested option to add:

stackablectl demo in monitoring --release 24.7

The default should be the latest stable release.

Examples (competing ideas, in no particular order)

stackablectl demo in monitoring # latest stable. Currently this deploys manifests from `main`

# Enforce a particular release
stackablectl demo in monitoring --release 24.7
stackablectl demo in monitoring --release dev

# Take any committish (stackableRelease derived from stack.yaml at that version)
stackablectl demo in monitoring --ref abcdef7
stackablectl demo in monitoring --ref release-24.7

# Or, enforce a branch (because the HEAD is what should be working. Random commits might cause surprises)
stackablectl demo in monitoring --branch release-24.7 # but must be a branch

Considerations:

  • --ref (Committish), or --branch (and check that it is a branch), or --release (we need to derive the ref).
    • We can work out the operator release, because at that version
    • We should ideally go with the most flexible (--ref), unless we cannot derive the release.
    • ⚠ There will still be hard coded refs in the stack/demo yamls, as well as scripts. This can lead to broken demos.
    • Specifying --release would remove the need for the stackableRelease key in stacks.yaml.
  • Caching - do we need to invalidate the cache if a ref/branch/release is specified?
  • Overlap with: 💥 'install' should install 'stable' instead of 'nightly' for operators/demos/etc... #212

Activity

  1. NickLarsenNZ commented on Nov 12, 2024

    @NickLarsenNZ
    MemberAuthor

    Not having this is making things really difficult at release time, because the current behaviour:

    • requires the demos main branch to be stable, which means...
    • changes needed for an upcoming release need to be held back in a next branch (which still can't be used by stackablectl without checking out the branch), and then...
      • The next branch gets mixed with changes that can work for the next release, as well as other changes that break it (eg: image tags that don't yet exist). This confusion could be avoided by using the 0.0.0-dev tags.
    • Near release time, the next branch gets merged - generally breaking the stability promise of the main branch.

    Notes:

    • No other repos at stackable treat main as a stable source, so demos should not either.
    • Demos are now versioned, so we only need to do this change before the demos main branch can be treated as dev/nightly/unstable.
  2. self-assigned this
    on Nov 13, 2024
  3. moved this to Ready for Development in Stackable Engineeringon Nov 25, 2024
  4. moved this from Ready for Development to Development: In Progress in Stackable Engineeringon Nov 25, 2024
  5. linked a pull request that will close this issuefeat: Select versions of demos & stacks #340on Dec 5, 2024
  6. moved this from Development: In Progress to Development: Waiting for Review in Stackable Engineeringon Dec 5, 2024
  7. moved this from Development: Waiting for Review to Development: In Review in Stackable Engineeringon Dec 5, 2024
  8. labrenbe commented on Dec 6, 2024

    @labrenbe
    Member

    We decided to implement the first option --release because users would typically want to install a stable version (--release dev still allows installing from main) while keeping the overall complexity as low as possible.

  9. moved this from In Progress to Done in Stackable End-to-End Coordinationon Dec 18, 2024
  10. moved this from Development: In Review to Development: Done in Stackable Engineeringon Dec 18, 2024
  11. moved this from Development: Done to Acceptance: In Progress in Stackable Engineeringon Jan 10, 2025
  12. moved this from Acceptance: In Progress to Done in Stackable Engineeringon Jan 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions