Design: Support for Additional Provisioners

[JoelProminic]

We talked @JustinProminic about extending Super.Human.Installer to support additional provisioners besides demo-tasks. These provisioners could be used to generate other kinds of VMs, like:

• "Additional" Domino Servers (existing organizational certifier). This should be mostly similar ot the current standalone Domino configuration
• Volt MX - still part of Domino ecosystem
• VyOS - unrelated installations that are useful for Prominic or other customers

To help organize the provisioners, we would probably group them by "Service type":

And then let the user select the provisioner, with options for customizing (will be discussed in a separate issue) or providing new provisioners.

The provisioner would then determine the required parameters in the Server Configuration interface. These interfaces will probably be hard-coded in the application. Custom applications will need to reuse the interfaces for existing provisioners. We will probably need a way to configure the GUI in the custom provisioners in the long term, but we can discuss this separately.

NOTE: these are early mockups to clarify the concept.

[MarkProminic]

I like the idea a lot, I would like to vote to be able to include Git repos for rapid changes to the source and testing those changes via SHI rather than by hand.

It would be tedious to constantly unzip a directory and move it to a directory every time, when it could just auto-pull the repo.

I would imagine these would be stored under a folder call /Assets/provisioners like demo-tasks currently is.

That would means we could reuse the DominoVagrant_demo-tasks.genericproj as the way to define the release version, and any other variables SHI needs to know what the provisioner is capable of.

Also, it would encourage the use of making Github repos for this for people to share their work.

[JoelProminic]

Yeah, I definitely want to make it easy to work with these templates with Git.

I envision the custom templates just pointing to directories that follow required conventions for Super.Human.Installer. So, this could be the GitHub repository itself, or a generated directory directory within the project.

Are you proposing we instead link to GitHub repository URL and download templates generated by convention in the GitHub actions? That might be better for continuous integration, but SHI would need to work with the Git API, as well as private tokens if the repository is private.

Note that one of the main goals for the custom provisioners is to make it easier for Prominic staff to create new Vagrant templates. So, we should think about how we would like to develop these templates.

[JoelProminic]

We shouldn't put the SHI configuration in the .genericproj file. This is a Moonshine configuration file, and we may eventually add options to support Maven or Gradle.

We'll probably want to use yml files for the metadata configuration, along with the configuration for #84 (though I see you have concerns about that issue).