Tracking pack changes from repo or git urls

[kevb]

Current swarm-sync track a single "config repo" which contains the definition of the cluster state (example: https://github.com/kevb/swarm-sync-example).

Right now, all packs are defined in this repo too, so it's easy to know if any pack changes.

I've now pushed a change to swarm-pack to allow installing a pack from an "official repository" of packs (https://github.com/swarm-pack/repository) or just directly from a git url.

To allow the same in swarm-sync, we need to be able to track changes in both the official repo and custom git urls.

Options:

1. Checkout and track both the official repo and custom URLs in swarm-sync and track them along with the main config repo, or
2. Make commands in swarm-pack to fetch the "version" for a given repo pack or for a custom URL/path.

Option 2 seems a little clunky as we will duplicate a lot of stuff between ss & sp.

Option 1 - we would need to decide what is a "version". I really like the git commit idea - can we use this? Does it "fit" in swarm-pack?

[vudknguyen]

My suggestion will be another option:

• Swarm pack will hold a responsibility to a registered repository
• It will have a new feature to track update for the installed packs, and there is a command to do update version just for an installed packs

The command would be

# Check for latest version of installed pack
swarm-pack outdated

# Auto update all installed packs to latest version
swarm-pack update

# Update to latest version of a pack
swarm-pack update <pack_name>

#Update to a specific version of a pack
swarm-pack update <pack_name> <version>

[kevb]

I think it could be a good idea. Just need to be careful that there are stacks involved as well. Values will be constructed by swarm-sync for a deployment/update so need to think how to handle it . Swarm-pack won't have this available untill you pass it in from swarm-sync.

…

On Sun, 3 Mar 2019, 22:57 Vu Nguyen, ***@***.***> wrote: My suggestion will be another option: - Swarm pack will hold a responsibility to a registered repository - It will have a new feature to track update for the installed packs, and there is a command to do update version just for an installed packs The command would be # Check for latest version of installed pack swarm-pack outdated # Auto update all installed packs to latest version swarm-pack update # Update to latest version of a pack swarm-pack update <pack_name> #Update to a specific version of a pack swarm-pack update <pack_name> <version> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAuwiKYELHHUSswFjr-UPWNV_QLc2P4ks5vS-LOgaJpZM4ba5Iq> .

[kevb]

Latest solution is SS calls SP->inspectPack() to get the latest commit but SS manages the state of what is currently deployed.

I'm not sure if we can move this responsibility to SP, but I'll leave this open for now for discussion.

[vudknguyen]

I checked the logic of that, seems to depend on the particular commit_hash of the pack with "inspect" API.

I think we can replace the commit_hash with version, so it only updates if a version is changed, not by the commit, can also expose the API upgrade that swarm-sync can call and pass value on

[kevb]

I agree in theory that version might be better than commit hash. But I have reservations:

• I really don't like keeping the version in package.json or another file. It's not immutable and prone to error. I like the definitive version to come from git tags and controlled by the CI, or something similar. I am open to having my mind changed : )

• I wonder what is the expect behaviour in general? Looking at flux, the idea is to watch branches and sync when the branch changes. If using version number, there's a question of what constitutes a "change" or a "release".

Let me know your thoughts

[kevb]

Seems like Helm uses version number, and version is always incremented for a commit, e.g. helm/charts@734a876

I wonder if it's possible to automate this or have a safeguard, like a pre-commit hook?