imperative
imperative copied to clipboard
zowe
Zowe profile / config details
For the ongoing work on the Zowe profile simplification, there is the notion of Global, Project (or team?) and User config files. It would be good to document what would be included or be part of Global config vs Project config to start with. This will help users a clear picture of when to use Global config vs Project config. There can be several possibilities - but having a recommendation on what goes where will help articulate the usage patterns and related recommendations. @MikeBauerCA @dkelosky
@MichaelABroadcom and @jelaplan - is this something that you could help with ?
@venkatzhub fully agree! For awareness to others reading this thread, our current documentation is contained within this blog and this file.
It would be ideal if the flow started with selecting a particular use case (e.g. using IDE tools to explore z/OS in real time, developing test automation or CI/CD pipelines leveraging the CLI, etc.) and environment (accessing mainframe services directly, using the API ML with SSO conformant services, etc.) and then provide a focused recommendation on how to BEST construct the config file for rollout to the rest of the team or enterprise.
The recommendation for a particular use case and environment should be simple. There are just a lot of variations to consider / document.
@MikeBauerCA - Thanks for the pointers to blog and the file. The file does have a lot of what I was thinking in terms of what a Global file should contain. To your point on on starting with a use case, so if we can crisp up that file to say something like: For IDE Tools - here is a sample Global config file, For CI/CD - here is a starter sample etc. This will help start the conversation from customers / users, and help us shape up the best practices based on the real world use cases.
I think we should advise people to make their config.json files self contained - that is put all their settings in a single file, be that a global version or a project version. The system makes it possible to take some settings from a global and some from a project file. For example, put base settings in the global and service settings in a project. But, it seems advisable to keep it simple and not advise people to do that. I think that is for more experienced, advanced users.
For Zowe Explorer and other VS Code extensions, I think we should initially focus on using a global config and have people store all their settings in that file.
For project profiles, the user mechanics of pointing to that config.json differs in CLI and IDE extensions. For the CLI, the user can go to a directory where the config is stored and then run commands. That is somewhat natural and I think very workable. But on IDE, it is less natural to pick a folder before working with files, members, etc. At present the convention we've discussed is to let a user pick a folder that contains the config file from the VS Code explorer to set context. That leaves a lot of room to miss the boat and to break things when unwittingly changing the current folder in VS Code explorer. But, Jelly and I have discussed ways to make folder selection part of the extension - for example, click a button and open a file manager window to pick/set a folder. Incorporating that task into the extension will make it self-contained so we can better guide people and lead them to the action. I think the term set a folder might be better than pick a folder because the user could set that folder and keep it set across sessions, etc.
I won't be surprised if people argue for supporting project files in VS Code and I think we'll need to get there. But, project config has some issues when it comes to VS Code. One is to do with identifying the folder where a config is stored. But, also, switching folders is from one project to another is surely more hassle in VS Code than in CLI where I can simply open another terminal or run a quick command to switch directories.
Yesterday, Peter H of IBM asked about a way for the user to identify where the config settings are coming from. This echoes Dan's idea to have a CLI command or option that can echo the source of the options used with a command. I like the premise of this idea. With the ability to inherit data from base profiles, to make global and project additive and the possibility of default values that come of the ether, it would be valuable to give the user some the ability to get feedback on where those values are coming from. I spoke with Gene a week or so back and suggested that the SDK deliver the config settings to the client in triplicates - key, value, source. The latter source value would indicate where it came from - such as file, node, etc. My intent with that ask was so that at when a UI could be built that can return an updated data object to the SDK.
End-user Zowe documentation describes how profiles from different team configuration files work in conjunction with each other.
An engineering whitepaper on how multiple configuration files are merged together provides recommendations on best practices and describes the detailed behavior for a variety of scenarios.
Since both of these documents have been published and are available on pubic web sites, we are closing this issue.
