Fields changed

description: Currently it is pretty hard to communicate a configuration error encountered when ELAPI initializes to the caller. We are limited to the error code (and message) but it is hard to communicate which target or sink the problem is related to.

I was envisioning that the dispatcher can internally be built to contain some verbose information that will report the processing of the config file, loading sink providers and initializing them. Then there will be a very simple utility that will:
1) Link with verbose version of the dispatcher
2) Take a config file and application name as arguments
3) Create validation dispatcher
4) Load all targets, sinks and providers.
5) Initialize all sinks and make sure that they can connect to their data storages.
=> Currently it is pretty hard to communicate a configuration error encountered when ELAPI initializes to the caller. We are limited to the error code (and message) but it is hard to communicate which target or sink the problem is related to.

I was envisioning that the dispatcher can internally be built to contain some verbose information that will report the processing of the config file, loading sink providers and initializing them. Then there will be a very simple utility that will:
1) Link with verbose version of the dispatcher
2) Take a config file and application name as arguments
3) Create validation dispatcher
4) Load all targets, sinks and providers.
5) Initialize all sinks and make sure that they can connect to their data storages.

Would be really nice to provide it in ELAPI 1.0 but I doubt I would have bandwidth.

description: Currently it is pretty hard to communicate a configuration error encountered when ELAPI initializes to the caller. We are limited to the error code (and message) but it is hard to communicate which target or sink the problem is related to.

I was envisioning that the dispatcher can internally be built to contain some verbose information that will report the processing of the config file, loading sink providers and initializing them. Then there will be a very simple utility that will:
1) Link with verbose version of the dispatcher
2) Take a config file and application name as arguments
3) Create validation dispatcher
4) Load all targets, sinks and providers.
5) Initialize all sinks and make sure that they can connect to their data storages.
=> Currently it is pretty hard to communicate a configuration error encountered when ELAPI initializes to the caller. We are limited to the error code (and message) but it is hard to communicate which target or sink the problem is related to.

I was envisioning that the dispatcher can internally be built to contain some verbose information that will report the processing of the config file, loading sink providers and initializing them. Then there will be a very simple utility that will:
1. Link with verbose version of the dispatcher
2. Take a config file and application name as arguments
3. Create validation dispatcher
4. Load all targets, sinks and providers.
5. Initialize all sinks and make sure that they can connect to their data storages.

Fields changed

component: SSSD => ELAPI
owner: somebody => dpal

THE ISSUE IS MOVED INTO ELAPI TRAC INSTANCE.

resolution: => wontfix
status: new => closed

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1382

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.