This yaml is similar to the 3rd scenario (create keyring & certificate), but create: false will be used to tell it not to create.
The result of this config should be that no JCL is executed, no system change occurs.
At maximum, validation could be performed to see if the keyring chosen is actually valid for zowe use.
But the point of this yaml would be that upon running zwe init certificate, the only thing it would do is convert from the setup.certificate structure to the certificate structure.
Proposal 2:
Just completely comment out the whole zowe.setup.certificate section and make clear that users should go right down to the zowe.certificate area in which they'll find
In other words, users need only alter the alias & end of file portions to get running.
defaults.yaml could have complicated defaulting to hide away the truststore section entirely I suppose.
Many users do not want Zowe to create a keyring. They just want to use their own keyring. This is possible and the requirements are documented at https://docs.zowe.org/stable/user-guide/configure-certificates#zowe-certificate-requirements but zowe does not provide clear documentation or intuition on how to make use of such keyrings.
Proposal 1:
Change example-zowe.yaml to add a 6th "certificate setup scenario"
It should look like this:
This yaml is similar to the 3rd scenario (create keyring & certificate), but
create: false
will be used to tell it not to create.The result of this config should be that no JCL is executed, no system change occurs. At maximum, validation could be performed to see if the keyring chosen is actually valid for zowe use.
But the point of this yaml would be that upon running
zwe init certificate
, the only thing it would do is convert from thesetup.certificate
structure to thecertificate
structure.Proposal 2:
Just completely comment out the whole
zowe.setup.certificate
section and make clear that users should go right down to thezowe.certificate
area in which they'll findIn other words, users need only alter the alias & end of file portions to get running. defaults.yaml could have complicated defaulting to hide away the truststore section entirely I suppose.