Zowe CLI V2 - zowe profiles create deprecated?

[FALLAI-Denis]

Hi,

Apparently with the move to Zowe CLI V2, the profile management commands are deprecated...
You can no longer / must create a profile using a zowe profiles create... command.
From what I understood from the documentation, you now have to directly edit the zowe.config.json or zowe.config.user.json files?

This is just unacceptable!

Our users are not Zowe CLI experts. They must be given simple and above all reassuring solutions: editing a file directly, with all the possible handling errors, is simply unacceptable.

[MikeBauerCA]

Hello @FALLAI-Denis, perhaps we could set up a call and I can help your team adopt team configuration and Zowe V2 LTS. A few notes that I would like to share here are:

• Zowe V1 LTS will continue to be supported for ~2.5 years so we do have some time to transition
• In Zowe V2 LTS, you can choose to continue using Zowe V1 LTS profiles. However, once you transition to use the new team configuration, you can no longer mix in Zowe V1 LTS style profiles.

Our users are not Zowe CLI experts.

• This was a driving factor behind the development of team configuration. An administrator at a site can develop the zowe.config.json and share with others in the organization. This way, you won't have every user spending time trying to create their profiles. We found users had difficulty keying in the profile creation commands and many did not know the connection information for services. V1 profiles had some challenges scaling as well - fields like host, user, and password were duplicated across many profiles making profile management challenging.

[FALLAI-Denis]

Hi @MikeBauerCA

The zowe.config.json file seems to define a hierarchy of profiles.
Some profiles can be typed and others not.
Profiles seem to inherit properties from their parents.

Problem: this hierarchy mechanism has an impact on the naming of profiles. The name of a profile becomes level1.level2....leveli...final.
This complicates the use of profiles and makes the use of hierarchies almost unusable.
It would have been preferable to manage imports and leave the profile declarations at the first level so as not to impact the profile naming scheme.
Similarly, it would have been better to use the profile type as a primary key and the profile name as a secondary key, which would have allowed the same name to be used for several types.

I took the example provided on the page https://docs.zowe.org/stable/user-guide/ze-profiles/#:~:text=Configuring%20team%20profiles%20Zowe%20CLI%20team%20profiles %20simplify,files%20with%20connection%20details%20for%20your%20mainframe%20services. to illustrate:

{
    "$schema": "./zowe.schema.json",
    "profiles": {
      "lpar1": {
        "properties": {
          "host": "192.86.32.67"
        },
        "profiles": {
          "my_zosmf": {
            "type": "zosmf",
            "properties": {
              "port": 10443
            },
            "secure": []
          },
          "my_tso": {
            "type": "tso",
            "properties": {
              "account": "",
              "codePage": "1047",
              "logonProcedure": "IZUFPROC"
            },
            "secure": []
          },
          "my_ssh": {
            "type": "ssh",
            "properties": {
              "port": 22
            },
            "secure": []
          },
          "my_zftp": {
            "type": "zftp",
            "properties": {
              "port": 21
            },
            "secure": []
          }
        }
      },
      "my_base": {
        "type": "base",
        "properties": {
          "rejectUnauthorized": false
        },
        "secure": ["user", "password"]
      }
    },
    "defaults": {
      "zosmf": "lpar1.my_zosmf",
      "tso": "lpar1.my_tso",
      "ssh": "lpar1.my_ssh",
      "zftp": "lpar1.my_zftp",
      "base": "my_base"
    },
    "plugins": []
  }

Solution without hierarchy:

{
    "$schema": "./zowe.schema.json",
    "exports": {
        "lpar1": {
            "properties": {
                "host": "192.86.32.67"
            },
        }
    },
    "profiles": {
        "zosmf": [{
            "my_zosmf": {
                "imports": ["lpar1"],
                "properties": {
                    "port": 10443
                },
                "secure": []
            }
        }],
        "tso": [{
            "my_tso": {
                "imports": ["lpar1"],
                "properties": {
                    "account": "",
                    "codePage": "1047",
                    "logonProcedure": "IZUFPROC"
                },
                "secure": []
            }
        }],
        "ssh": [{
            "my_ssh": {
                "imports": ["lpar1"],
                "properties": {
                    "port": 22
                },
                "secure": []
            }
        }],
        "zftp": [{
            "my_zftp": {
                "imports": ["lpar1"],
                "properties": {
                    "port": 21
                },
                "secure": []
            }
        }],
        "base": [{
            "my_base": {
                "imports": [],
                "properties": {
                    "rejectUnauthorized": false
                },
                "secure": ["user", "password"]
            }
        }],
        "defaults": {
            "zosmf": "my_zosmf",
            "tso": "my_tso",
            "ssh": "my_ssh",
            "zftp": "my_zftp",
            "base": "my_base"
        },
        "plugins": []
    }

• there is only one profiles object, no hierarchy
• it consists of properties for each type of managed profile
• these profile type properties are arrays of profile objects
• a profile can import from 0 to N declarations of shared properties, multiple inheritance, if several imports declare the same properties, the last import is taken into account (in the order of declaration in the array)
• a profile can define its own properties which take priority over imported properties
• several profiles can have the same name if they are of different types

[FALLAI-Denis]

Confer #1413

[Marty850]

Hi,
I also ran into that issue. We use the zowe cli in a jenkins job for the deployment of our rexx scripts. Jenkins checks out the files from git and copies them to the mainframe.

The first step in our jenkins job is installing the zowe cli, the second is the create profile command. Our build team don't want zowe pre installed on the build systems so we have to do the installation and configuration by script every time. Editing a file in the jenkins job to create the profile would be very unhandy and I don't know if it will work.

[MikeBauerCA]

Hi @Marty850, do you use a Jenkinsfile to drive your automation?

If you do not already do so, you could store your Jenkins automation in source control. This provides several benefits and details are described here.

If you go this route, you can check in a zowe.config.json into your project and the Jenkins pipeline would read from it. You would no longer need to maintain profile creation commands - just install the CLI in your pipeline run and leverage the zowe.config.json. You would not need to programmatically edit the config, just check it into source control. Zowe can also read from specially named environment variables like ZOWE_OPT_USER and ZOWE_OPT_PASSWORD so you can leverage Jenkins secret storage to manage these.

[FALLAI-Denis]

@Marty850

Same use cas for us with Jenkins.

Since Zowe CLI V2, we deposit in the root folder Git Repositories a zowe.config.json file containing the profiles necessary for this Git Repository.
The references (host property) to z/OS partitions (lpar) are always the same, but we have several z/OS partitions and not all of them are affected by a Git repository.
We don't use a hierarchy in zowe.config.json because it impacts the value of the host property.

In Jenkins, either the zowe.config.json file is present in the Git Repository and it is used, or it is absent and then in this case we start by copying a "universal" zowe.config.json file containing all the profiles of all our z/OS partitions.
The Jenkins user is created on each of the z/OS partitions as a service account.
The Jenkins user and password for the z/OS partition is passed as a parameter to each Zowe CLI command.

Note that this remains a transitional solution, as we are in the implementation phase of IBM Dependency Based Build which removes the need to use Zowe CLI to communicate with z/OS partitions:

• the Jenkins pipeline start an agent on the z/OS partition
• the Jenkins agent clones the Git repository on z/OS (Git for z/OS)
• IBM Dependency Based Build works on cloned Git repository on z/OS

[Marty850]

Thank you @MikeBauerCA and @FALLAI-Denis! Using zowe.config.json works for my use-case

[github-actions[bot]]

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.