[feature request] Ability to import external provisioners in `init`

[mathieu-benoit]

It would be very helpful to be able to import existing shared templates coming from public/private Git repos and public/private OCI registries.

Today, I need to manually copy any custom provisioners from Workload/Repo to Workload/Repo, not very convenient. And could lead to outdated version, inconsistency between workloads/projects, etc.

An idea could be to have a new --template or --import parameter in the score-compose init command?

This will add more provisioners in addition to the default ones.

Another idea, could also be to have a public repo in the score-spec Org where the community could share public shared provisioners, examples:

• service
• redis-dapr-state-store

[astromechza]

@mathieu-benoit why not use curl or cp to pull in the provisioners?

In terms of the UNIX philosophy I'd prefer that score implementations didn't get involved in working out where to get custom provisioners from or how to authenticate against remote repositories. I'd prefer folks used one of the following approaches:

1. Check the custom provisioners into the repo in .score-compose/ and only add the .score-compose/{state.yaml,mounts,99-default.provisioners.yaml} to the gitignore.
2. curl / rsync a remote file or files as a second step in the developer instructions or Makefile

It gets complicated if we offload that to score init, because then it needs to start understanding how to authenticate and secure a remote file download, which frequently gets complicated inside developer networks.

[mathieu-benoit]

Yeah, that's for sure that curl, wget, cp, rsync or oras can be used. And offloading the auth part outside score-compose init is indeed preferable too: using existing tools outside score-compose, not adding unnecessary maintenance for this in score-compose, etc. And same applies to score-k8s.

Maybe just examples or explicit documentation could be added in score.dev to illustrate this is enough.

[jayonthenet]

I would rather see a solution inside score-compose. If you're an enterprise platform team trying to provide a seamless platform experience to developers, then the ability to roll out a standard local resource set, which can also be kept current from a central point, is very valuable. Trying to get hundreds, possibly thousands, of developers to consistently use a script wrapper spun around the tooling is not going to work in most cases.

[astromechza]

Thanks @mathieu-benoit / @jayonthenet

Another effective option would be to use git submodules to check out a number of provisioner files from a repo B when you checkout repo A.

But this also aligns with a similar conversation we had about multi-app Score projects and how to make sure folks are using the right options. Because adding a cli option like --import-provisioner-uri would be roughly equivalent to a wrapping script because you'll need to communicate and ensure that your hundreds of devs are using the right cli options.

Perhaps a universal manifest file is needed?

$ cat score.conf
common: {}
score-compose:
  import-provisioners:
    - uri: file://./00-customer.provisioners.yaml
    - uri: https://raw.github.com/awdawdawdawd/01-custom.provisioners.yaml
score-k8s:
  import-provisioners:
    - uri: https://raw.github.com/awdawdawdawd/01-custom.provisioners.yaml