At the moment if we deploy only the basic tdp-collection but edit the vars for instance by mentioning in addition the tdp-extra collection, some components of the tdp-extra collection which do not exist on the cluster will have to be restarted or configured according to the generate_stale_sch_logs function which will always fail when launching a deployment with previously tdp plan reconfigure.
This is wrong and it should only be the other way around. if several collections are deployed we can chose to only reconfigure the services of one collection instead of all and for this reason the --collection-path option comes in handy if all collections have been defined in a path in an .env file. Therefore all potential restarted or configured services/components must exist before and have to be checked for it.
At the moment if we deploy only the basic tdp-collection but edit the vars for instance by mentioning in addition the tdp-extra collection, some components of the tdp-extra collection which do not exist on the cluster will have to be restarted or configured according to the
generate_stale_sch_logsfunction which will always fail when launching a deployment with previouslytdp plan reconfigure.This is wrong and it should only be the other way around. if several collections are deployed we can chose to only reconfigure the services of one collection instead of all and for this reason the
--collection-pathoption comes in handy if all collections have been defined in a path in an .env file. Therefore all potential restarted or configured services/components must exist before and have to be checked for it.