v3: Deprecate `base` profiles in favor of `nesting` team profiles

[zFernand0]

The base profiles have been a standard feature in Zowe CLI configuration management for many years. However, they have some limitations in terms of flexibility and reusability. As a result, the nesting structure of "team profiles" has been introduced to address these limitations. By deprecating the base profiles and replacing them with the more flexible nesting structure, teams can now reuse profile properties much more easily. The nesting structure also provides a more modular approach to configuration management, enabling teams to create more granular configurations that better reflect their unique requirements. By embracing this new structure, organizations can improve their overall efficiency and reduce the time and effort required for configuration management.

[t1m0thyj]

Based on discussion with @zFernand0 and @gejohnston, here is a more detailed proposal of how we could deprecate base profiles.

Today with Zowe v2, when you run zowe config init you end up with a config file like the following:

Click to expand zowe.config.json

{ "$schema": "./zowe.schema.json", "profiles": { "zosmf": { "type": "zosmf", "properties": { "port": 443 }, "secure": [] }, "tso": { "type": "tso", "properties": { "account": "", "codePage": "1047", "logonProcedure": "IZUFPROC" }, "secure": [] }, "ssh": { "type": "ssh", "properties": { "port": 22 }, "secure": [] }, "base": { "type": "base", "properties": { "host": "example.com", "rejectUnauthorized": false }, "secure": [ "user", "password" ] } }, "defaults": { "zosmf": "zosmf", "tso": "tso", "ssh": "ssh", "base": "base" }, "autoStore": true }

If you want to update your config for connections to multiple LPARs, you have to remove the base profile and reorganize its properties like this:

Click to expand zowe.config.json

{ "$schema": "./zowe.schema.json", "profiles": { "lpar1": { "profiles": { "zosmf": { "type": "zosmf", "properties": { "port": 443 }, "secure": [] }, "tso": { "type": "tso", "properties": { "account": "", "codePage": "1047", "logonProcedure": "IZUFPROC" }, "secure": [] }, "ssh": { "type": "ssh", "properties": { "port": 22 }, "secure": [] } }, "properties": { "host": "example1.com", "rejectUnauthorized": false }, "secure": [ "user", "password" ] }, "lpar2": { "profiles": { "zosmf": { "type": "zosmf", "properties": { "port": 443 }, "secure": [] }, "tso": { "type": "tso", "properties": { "account": "", "codePage": "1047", "logonProcedure": "IZUFPROC" }, "secure": [] }, "ssh": { "type": "ssh", "properties": { "port": 22 }, "secure": [] } }, "properties": { "host": "example2.com", "rejectUnauthorized": false }, "secure": [ "user", "password" ] } }, "defaults": { "zosmf": "lpar1.zosmf", "tso": "lpar1.tso", "ssh": "lpar2.ssh" }, "autoStore": true }

Or if you run zowe auth login apiml to obtain an APIML token it will add a second base profile. Now it is confusing which one you want to use:

Click to expand zowe.config.json

{ "$schema": "./zowe.schema.json", "profiles": { "zosmf": { "type": "zosmf", "properties": { "port": 443 }, "secure": [] }, "tso": { "type": "tso", "properties": { "account": "", "codePage": "1047", "logonProcedure": "IZUFPROC" }, "secure": [] }, "ssh": { "type": "ssh", "properties": { "port": 22 }, "secure": [] }, "base": { "type": "base", "properties": { "host": "example1.com", "rejectUnauthorized": false }, "secure": [ "user", "password" ] }, "base_apiml": { "type": "base", "properties": { "host": "example2.com", "port": 7554, "tokenType": "apimlAuthenticationToken" }, "secure": [ "tokenValue" ] } }, "defaults": { "zosmf": "zosmf", "tso": "tso", "ssh": "ssh", "base": "base_apiml" }, "autoStore": true }

In the future, running zowe config init could generate a config file without a base profile like the following:

Click to expand zowe.config.json

{ "$schema": "./zowe.schema.json", "profiles": { "zosmf": { "type": "zosmf", "properties": { "port": 443 }, "secure": [] }, "tso": { "type": "tso", "properties": { "account": "", "codePage": "1047", "logonProcedure": "IZUFPROC" }, "secure": [] }, "ssh": { "type": "ssh", "properties": { "port": 22 }, "secure": [] } }, "properties": { "host": "example.com", "rejectUnauthorized": false }, "secure": [ "user", "password" ], "defaults": { "zosmf": "zosmf", "tso": "tso", "ssh": "ssh" }, "autoStore": true }

Then if you want to update your config for connections to multiple LPARs, you could just indent the top-level "profiles", "properties", and "secure" objects and wrap them inside an "lpar1" parent profile.

And if you run zowe auth login apiml to obtain an APIML token, it could create a new "apiml" profile at the top level. Then any service profiles that should connect through APIML could be added as subprofiles.

Click to expand zowe.config.json

{ "$schema": "./zowe.schema.json", "profiles": { "apiml": { "properties": { "host": "example2.com", "port": 7554, "tokenType": "apimlAuthenticationToken" }, "secure": [ "tokenValue" ] } "zosmf": { "type": "zosmf", "properties": { "port": 443 }, "secure": [] }, "tso": { "type": "tso", "properties": { "account": "", "codePage": "1047", "logonProcedure": "IZUFPROC" }, "secure": [] }, "ssh": { "type": "ssh", "properties": { "port": 22 }, "secure": [] } }, "properties": { "host": "example1.com", "rejectUnauthorized": false }, "secure": [ "user", "password" ], "defaults": { "zosmf": "zosmf", "tso": "tso", "ssh": "ssh" }, "autoStore": true }

[adam-wolfe]

If we decided to deprecate base profiles in V3, is there a way that we could tell users with base profiles that base profiles are going away in V4 without being too annoying (for lack of a better word)? Or would it be adequate to just add a note in the documentation?

I.e., how would people learn that base profiles will not be supported in v4 (if that is what we decide to do)?

[zFernand0]

We could the deprecation information in multiple places:

1. On hover over the properties of a base profile
2. As a comment right below the "type": "base" (if it doesn't exist) after a command is executed. May need to place this in a common location (config.load?) so that ZE can take advantage of this as well.
3. As a warning, whenever a zowe config command is issued

[adam-wolfe]

Remaining concerns:

• Some users feel that team config is too complicated and are not comfortable with nesting profiles.
• What do we gain by removing base profiles, or what do we lose by keeping base profiles a part of team config?