Add Examples (was: filename in release)

[TJM]

... as per the changelog in v0.2.12:

IMPROVEMENTS:

- Plugin now reports its version to Vault server. You can see it with `vault plugin list` command.
- Remove version number from the binary file name (now `artifactory-secrets-plugin`, vs `artifactory-secrets-plugin_v0.2.6`) now that it registers as 'versioned' plugin with Vault server.
- Update README on how to register plugin to reflect this change of binary name.
- Update Makefile to use GoRelease (same as GitHub Action) to build binary for development process.

The problem is that when upgrading the plugin on a cluster, you will need both binaries on the system at the same time, so you will need to rename it to have the version in the name or do something funky like _new or _old ??

I can handle this in my packer script, but it was easier to just have the name be the version.

Or.. maybe I am doing something wrong? :)

something like:

#!/bin/bash -e
## LOTS OF OTHER STUFF
  ## Artifactory Secrets Plugin - keep the name artifactory-secrets-plugin_v(VERSION), to allow safe upgrades
  ARTIFACTORY_PLUGIN_VERSIONS="0.2.11 0.2.12"
  for ver in ${ARTIFACTORY_PLUGIN_VERSIONS}; do
    curl -sSOL "https://github.com/jfrog/artifactory-secrets-plugin/releases/download/v${ver}/artifactory-secrets-plugin_${ver}_linux_amd64.zip"
    curl -sSL "https://github.com/jfrog/artifactory-secrets-plugin/releases/download/v${ver}/artifactory-secrets-plugin_${ver}_checksums.txt"|grep linux_amd64  > artifactory-secrets-plugin-checksums.txt
    sha256sum -c artifactory-secrets-plugin-checksums.txt
    unzip -jo "artifactory-secrets-plugin_${ver}_linux_amd64.zip" "artifactory-secrets-plugin*"
    if test -f "artifactory-secrets-plugin_v${ver}"; then
      sudo mv "artifactory-secrets-plugin_v${ver}" "${VAULT_PLUGINS_DIR}/artifactory-secrets-plugin_v${ver}" # Keep versioned binary
    else
      sudo mv artifactory-secrets-plugin "${VAULT_PLUGINS_DIR}/artifactory-secrets-plugin_v${ver}" # make the binary versioned
    fi
    sudo chown root:root "${VAULT_PLUGINS_DIR}/artifactory-secrets-plugin_v${ver}"
    sudo chmod 755 "${VAULT_PLUGINS_DIR}/artifactory-secrets-plugin_v${ver}"
  done

[alexhung]

The way I understand (and assume) is that when Vault server mount/enable a plugin, it starts a new process(?) thus keeping it in memory. I can be wrong though. Overwriting the binary with new version won't affect existing mounted plugin. And to distinguish between old and new during registration, the option -version would be used.

(Of course one should make a backup copy (if not already) of the existing binary before copying in the new version.)

I'm open to revert back to including version in file name if it makes life easier. The reason for the switch is to follow common convention where binary name does not include version.

[TJM]

I am not saying to change for me. Perhaps my vault cluster in a Google MIG is overly complex. I actually think the upgrade instructions say to backup the old binary, but maybe that was to be able to move back to the previous version. I think it said to not overwrite the binary, but it seems like it could stop/start that process at any time, so I had planned to keep the full name.

DOC: https://developer.hashicorp.com/vault/docs/upgrading/plugins

the plugin binary in this example has the version on it tho :-/

[alexhung]

True. When I examine a few plugins in the both official and partner plugins, all of the binaries do not contain the version string.

[TJM]

I guess I will use my script above to keep the version string... I wonder if something like that would be useful? It is part of our packer scripts to build a vault image.

[alexhung]

Feel free to open a PR to add your script to the project (in ./scripts directory?).

[TJM]

Interesting idea... it could for sure be in scripts or maybe "examples" or something? I could actually include more stuff (Terraform)

[alexhung]

'examples' is better fit, along with references to them in README