search

zowe / zowe-install-packaging

Packaging repository for the Zowe install scripts and files
Eclipse Public License 2.0
26 stars 52 forks source link

zwe start -c /path/to/custom.zowe.yaml ignore `custom.zowe.yaml` #3848

Closed cumarav closed 2 weeks ago

cumarav commented 3 weeks ago

Describe the bug

I've installed zowe. I want to be able to start zowe with customized set of APIML services so I've created copy of zowe.yaml - custom.zowe.yaml in which I've enabled a additional service.

I've stopped running zowe and trying to start it with: bin/zwe start -c custom.zowe.yaml

I the job log I see -

2024-06-04 10:52:37.016 <ZWELNCH:16777405> ZWESVUSR INFO ZWEL0023I Zowe YAML config file is 'FILE(/etc/zowe2/zowe.yaml)'       
2024-06-04 10:52:37.016 <ZWELNCH:16777405> ZWESVUSR INFO ZWEL0024I HA_INSTANCE_ID is 'de63'                                    
2024-06-04 10:52:37.024 <ZWELNCH:16777405> ZWESVUSR INFO ZWEL0017I ROOT_DIR is '/etc/zowe2'                                    
2024-06-04 10:52:37.031 <ZWELNCH:16777405> ZWESVUSR INFO ZWEL0069I Configuration is valid

I cannot find any reference to custom.zowe.yaml at all. -c parameter just ignored.

Expected behavior As -c path/to/zowe.yaml parameter is MANDATORY - zowe should use it custom.zowe.yaml should be applied with the higher precedence that default config or instead of default config.

Additional context zowe 2.16

balhar-jakub commented 3 weeks ago

When you were looking into the actual jobs, the additional service wasn't started, just to validate?

If that is the case @Martin-Zeithaml @jp669844 this seems like a relevant bug.

Martin-Zeithaml commented 3 weeks ago

zwe start uses the config custom.zowe.yaml to find, what is the started task name and will start that STC. You probably did not changed that or the default value was used. And your launcher STC is coded with:

//STDENV   DD  *                             
_CEE_ENVFILE_CONTINUATION=\                  
_CEE_RUNOPTS=HEAPPOOLS(OFF),HEAPPOOLS64(OFF) 
_EDC_UMASK_DFLT=0002                         
CONFIG=/etc/zowe2/zowe.yaml
/*

zwe start is not modifying STC before the execution.

JoeNemo commented 3 weeks ago

It is probably better to run this under SDSF or EJES or Sysview, I don't know how well these cases are documented.

Martin-Zeithaml commented 3 weeks ago

SDSF or SYSVIEW will not help, the config path is coded inside the JCL.

zwe start is only a way how to start STC from unix. Inside the start command there is basically only /S ZWESLSTC.

If you make additional changes to config or rename config, it is up to user to take corresponding actions:

The last 2 bullets are the reason, why zwe start is so simple (and stupid). It is not checking config in STC and command. Which could lead to the situation you described: config1 is used to start zowe which will use config2.

cumarav commented 3 weeks ago

When you were looking into the actual jobs, the additional service wasn't started, just to validate?

If that is the case @Martin-Zeithaml @jp669844 this seems like a relevant bug.

Yes, expected service was down after restart. (other changes has not been applied as well) Looks like bin/zwe read only STC name from YAML to start but it contains path to zowe.yaml which it should start. It does not make those 2 files interpolation

JoeNemo commented 2 weeks ago

We continue to desire other 3rd-party products to be supported in addtion to SDSF. @Martin-Zeithaml is looking at Sysview.

MarkAckert commented 2 weeks ago

I agree with Martin that we should keep the zwe start command behavior as-is, and we should further clarify the behavior of the start command in the help text. It should be front and center that the zowe.yaml config is only being used to identify an already-configured instance of Zowe, and any changes to the zowe.yaml config require re-running related zwe commands before issuing zwe start.