Open FALLAI-Denis opened 2 years ago
After some discussion, we considered this issue to have two essential parts to it.
The prefix addition of `typeto profile names after running the
zowe config conver-profilescommand._ As part of the design, we introduced aliases that allowed users to not have to change their scripts even though the profile names might be different. In order to achieve this goal, we allowed for a V1 profile named
LPAR1to be referenced as
LPAR1OR
type_LPAR1. This means that
zowe files list ds HLQ.DATASET --zosmf-p LPAR1should still work after running the
zowe config convert` command.
C:\Users\USER\test>zowe --version 7.11.1 C:\Users\USER\test>zowe profiles list zosmf --show-contents - name: LPAR1 contents: host: my.host.net port: 1234 rejectUnauthorized: false protocol: https - name: LPAR2 (default) contents: port: 443 rejectUnauthorized: true protocol: https Warning: The command 'profiles list' is deprecated. Recommended replacement: The 'config list' command C:\Users\USER\test>zowe config list C:\Users\USER\test>zowe files list ds USER.public.c* --zosmf-p LPAR1 Enter the user name for your service (will be hidden): Enter the password for your service (will be hidden): USER.PUBLIC.CBL USER.PUBLIC.CNTL C:\Users\USER\test>zowe config convert Detected 2 old profile(s) to convert from Zowe v1 to v2. Are you sure you want to continue? [y/N]: y Converted zosmf profiles: LPAR1, LPAR2 Your new profiles have been saved to C:\Users\USER\.zowe\zowe.config.json. Run "zowe config edit --global-config" to open this file in your default editor. Your old profiles have been moved to C:\Users\USER\.zowe\profiles-old. Run "zowe config convert-profiles --delete" if you want to completely remove them. If you would like to revert back to v1 profiles, or convert your v1 profiles again, rename the 'profiles-old' directory to 'profiles' and delete the new config file located at C:\Users\USER\.zowe\zowe.config.json. C:\Users\USER\test>zowe profiles list zosmf --show-contents An error occurred trying to list profiles. Profile IO Error: A Zowe V1 profile operation was attempted with a Zowe V2 configuration in use. Warning: The command 'profiles list' is deprecated. Recommended replacement: The 'config list' command C:\Users\USER\test>zowe config list profiles: zosmf_LPAR1: type: zosmf properties: host: my.host.net port: 1234 rejectUnauthorized: false protocol: https secure: (empty array) zosmf_LPAR2: type: zosmf properties: port: 443 rejectUnauthorized: true protocol: https secure: (empty array) defaults: zosmf: zosmf_LPAR2 autoStore: true C:\Users\USER\test>zowe files list ds USER.public.c* --zosmf-p LPAR1 Enter the user name for your service (will be hidden): Enter the password for your service (will be hidden): Stored properties in C:\Users\USER\.zowe\zowe.config.json: user, password USER.PUBLIC.CBL USER.PUBLIC.CNTL C:\Users\USER\test>
Hopefully this serves as an explanation to how the new name shouldn't have impacted end users (too deeply) when converting from V1 profiles to V2 Team Config using the zowe config convert-profiles
command.
Next steps:
documentation
enhacement
There is a slight problem with the AutoStore functionality (which I will create an issue for).
After the demonstration, I noticed that the user and password were stored in a new LPAR1
profile, which caused the same command zowe files list ds HLQ.DATASET --zosmf-p LPAR1
to fail since it does not merge the contents with zosmf_LPAR1
(i.e. by design we don't merge profiles of the same type, only with base
).
What should have happened is that, since we detected that we were using an aliased name, the AutoStore functionality should have saved the credentials in the new profile (zosmf_LPAR1
) instead of creating a new one (LPAR1
).
C:\Users\USER\test>zowe files list ds USER.public.c* --zosmf-p LPAR1 Enter the host name of your service: (Ctrl+C) Stored properties in C:\Users\USER\.zowe\zowe.config.json: host (THIS LINE SHOULD NOT APPEAR) Command Error: Expect Error: Required parameter 'hostname' must be defined C:\Users\USER\test>zowe config list profiles: zosmf_LPAR1: type: zosmf properties: host: my.host.net port: 1234 rejectUnauthorized: false protocol: https secure: (empty array) zosmf_LPAR2: type: zosmf properties: port: 443 rejectUnauthorized: true protocol: https secure: (empty array) LPAR1: properties: user: (secure value) password: (secure value) secure: - user - password defaults: zosmf: zosmf_LPAR2 autoStore: true C:\Users\USER\test>
Thank you for raising this enhancement request. The community has 90 days to vote on it. If the enhancement receives at least 5 upvotes, it is added to our development backlog. If it receives fewer votes, the issue is closed.
Hi,
With Zowe CLI V1, we had chosen to name all our profiles according to the name of the accessed z/OS LPAR.
So all profiles, whether z/OSMF, FTP, SSH, TSO, ENDEVOR... had the same name.
In addition, the profiles names were imposed on all our users because they are used in tool settings, including VS Code extensions, (settings managed at the Workspace level, i.e. a Git Repository, and shared by all users of this Git repository).
When switching from Zowe CLI V1 to Zowe CLI V2, the profile migration procedure renamed them all, by assigning them a name of the form "type-old_name"!
In fact, after migration, no tools were working anymore...
I think this is related to an architecture issue in the
zowe.config.json
file:profiles
, and thetype
of the profile is just an attributetype
should have been the primary key in theprofiles
array and the profile name should have been a secondary key. This would have made it possible to migrate the profiles while keeping their names and not to create any constraint on the uniqueness of the profile name.To put our tools back into operation, we had to rename all the profiles in the settings by applying a new naming convention:
Corollary, the profiles had to be renamed in the
zowe.config.json
file. But there is no Zowe CLI command to rename a profile... so the recoding had to be done manually directly in thezowe.config.json
file... This led to the loss of all credentials... which all had to be recreated as the profiles were used.We are absolutely not satisfied with these impacts suffered during the transition from Zowe CLI V1 to Zowe CLI V2.