zowe / zowe-cli

Zowe CLI
Eclipse Public License 2.0
108 stars 85 forks source link

Zowe CLI V2 - Regression on profile naming, malfunction of our tools and loss of credentials #1403

Open FALLAI-Denis opened 2 years ago

FALLAI-Denis commented 2 years ago

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:

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.

zFernand0 commented 1 year ago

After some discussion, we considered this issue to have two essential parts to it.

  1. Renaming of a profile causes loss of credentials. This is a known limitation and we can track it in this issue: https://github.com/zowe/zowe-cli/issues/1405
  2. The prefix addition of `typeto profile names after running thezowe 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 namedLPAR1to be referenced asLPAR1ORtype_LPAR1. This means thatzowe files list ds HLQ.DATASET --zosmf-p LPAR1should still work after running thezowe config convert` command.

    Here is a quick demonstration

    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:


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).

Details

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>

github-actions[bot] commented 1 year ago

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.