Validate and block on required/ custom parameters

[anilmurty]

Is your feature request related to a problem? Please describe.
Some SDLs (for example the kava node SDL in omnibus) require that the base parameter be updated with a use specific value (in case of kava node, it is the SNAPSHOT_URL). Since Console hides the params in the UI to reduce cognitive overload, it is easy for the user to miss updating them.

Describe the solution you'd like
Console should support validating required URLs and surfacing them up in the parameter editor step. Suggested design would be:

1. Any missing, required parameters would be marked with asterisk
2. The parameter editor fields that are normally minimized under the specific service name, would be open and exposed.
3. A message would be shown at the top (right under the service name) indicating that the required parameters need to be filled in and a link to the SDL that contains comments would be provided.

Describe alternatives you've considered
Provide instructions to users to update and have them use the import function to fill in the custom SDL. While this is a workable solution, it doesn't result in the best "one-click" user experience we desire.

[anilmurty]

@chainzero @jtary @aktdenis - how does this approach sound to you?

[jtary]

@anilmurty sounds good to me. I was thinking of using a format like this for the env variables:

env:
  - MYENVAR={{description of value|optional default value}}

If the default value is defined, the parameter becomes optional. If only the description is provided, the field must be provided by the user at deployment.

Thoughts?

[anilmurty]

@jtary - are you suggesting changing the annotation in the SDL itself (that would be a bigger lift)? or, is this just in the console code (in which case, sounds good to me). I guess we also would need to define some metadata somewhere that describes what fields are required, right?

[aktdenis]

just an idea... we could provide some additional guidance below the field which is required.

[jtary]

I am talking about changing the SDL themselves. Ultimately that's the only "input" into the console, and the only thing we have to use as far a data about what is required. The format is deliberately still valid SDL, it would just be up to the client weather it supports the format.

There is probably an alternate way to represent the data that would fail more gracefully if the client didn't understand the special meaning. Just wanted to get the discussion going.