Inconsistent template handling

[jojje]

Problem

Templates exist in the web console to allow users to create a set of defaults for different user tasks/goals. A template is a set of pod values that can be referenced by a name or identifier, and acts as default values when creating a pod. An alternative to having to retype the same information over and over again, saving not only keyboard strokes, but also reducing the risk of typos or deviations from the intended configuration for pods meant to be launched with the same default configurations.

In the CLI however, the template application is unclear, or rather undefined. This means there is no way for a user to tell in advance what configuration values will be applied to what create request fields. This means specifying template-id as an option is currently useless since the user can't rely on anything specified in the template being applied, nor do they know how templates will interfere or not with any command options or option defaults.

This leads to users having to specify every single configurable value on the create pod command line every time in order to ensure they get the expected result when a pod is created.

Root cause

Option resolution order is not specified.

Specifically, there is no documentation or prior discussion (that I can find) which defines what the resolution order should be between the four following potential sources for a given configuration value in the create request.

1. Explicitly provided CLI option values (by the user)
2. Template defined values
3. Implicit CLI option values (option defaults)
4. Backend API default values

The order of these four is my proposal for an intuitive resolution order from a user's perspective. Let me know your thoughts on this order.

Solution

1. Agree on the resolution order first.
2. Define the list of changes required to make template handling intuitive (for end users), internally consistent, and consistent with the web console.
3. Create specific issues to close gaps not covered by existing issues and PRs.

Coverage

This section lists the known discrepancies leading to inconsistent template application, along with open issues and PRs that aim to tackle part of this discrepancy. As of now it's a draft based on me just having done brief research on this issue, so feel free to comment on anything missing.

The following need be pulled from the template when such information is not explicitly set on the command line by the user, else the CLI defaults should be used and those should be consistent with the web console defaults in order to adhere to the principle of least surprise.

• Image, Issue: Specifying --templateId should not require to specify --imageName #162, PR: Make --imageName optional when --templateId is specified #220
• Container start command, Seems the defaults for the backend is to pull these values from the template, and the CLI's default value of nil allows this template propagation already.
• Disk & Volume size, Issue: Specifying --templateId does not apply disk and volume size/path settings #163, PR: Fix templateId not applying disk and volume settings from template #219
• Volume mount point, when missing (the default value shown in the web console accepted) the default should be consistent with the Web Console's default (currently web console uses /workspace and CLI uses /runpod). Issue: -, PR: -
• Ports, HTTP and TCP. Same as for start command.
• Environment variables. Same as for start command.