Bug 1017042

config files should be under /etc.
I'm not sure we shouldn't override this file. i'd expect it will break the app on upgrades.

> This file is editable, if one need to change anything in it like log level it is here in this file where to change it. So, logically it is a config file.

This is not config file. It should not be modified, unless there is a good reason for local temporary problem determination.

The problem is that jboss does not support proper packaging, overriding attributes but entire file, and we cannot perceive application specific core file that *IS* changing each version, and controlling how application actually runs.

What we have done is generate the file out of template, so we can add specific variables within this file as $getstring('XXX') which will be gotten out of /etc/ovirt-engine/engine.conf[.d/*].

So if you have specific behaviors that should remain after upgrade we can consider to include these.

I though several times to include the log, however, I realized that there are requests to add specific components which we cannot anticipate ahead, so I dropped the idea.

Please reopen if have any more input.
Thanks!

> So if you have specific behaviors that should remain after upgrade we can
> consider to include these.

Yes I have - debug log level. Please do anything so I, we (QE), customers can define DEBUG level somewhere in /etc, thus it would be "save" from being overwritten. It is super annoying to find a bug and then discover that default log level is useless (as upgrade did overwrote it). And INFO log level makes our devs not very excited.

if this only for QE we can add a variable at /etc/ovirt-enigne.conf[.d/*], example:

ENGINE_JBOSS_LOGGING="<logger category=\"org.ovirt.engine.core.bll\"><level name=\"DEBUG\"/></logger>"

this will injected directly into the jboss configuration under <subsystem xmlns="urn:jboss:domain:logging:1.1">.

please confirm this is sufficient.

We define this:

<!-- Only the engine messages go here: -->
      <file-handler name="ENGINE" autoflush="true">
        <level name="DEBUG"/>
        <formatter>
          .....
<logger category="org.ovirt.engine.core.bll">
        <level name="DEBUG"/>

(In reply to Jiri Belka from comment #6)
> We define this:
> 
> <!-- Only the engine messages go here: -->
>       <file-handler name="ENGINE" autoflush="true">
>         <level name="DEBUG"/>
>         <formatter>
>           .....
> <logger category="org.ovirt.engine.core.bll">
>         <level name="DEBUG"/>

ENGINE_JBOSS_ENGINE_ATTRS="autoflush=\"true\""
ENGINE_JBOSS_LOGGING="<logger category=\"org.ovirt.engine.core.bll\"><level name=\"DEBUG\"/></logger>"

(In reply to Alon Bar-Lev from comment #7)
> (In reply to Jiri Belka from comment #6)
> > We define this:
> > 
> > <!-- Only the engine messages go here: -->
> >       <file-handler name="ENGINE" autoflush="true">
> >         <level name="DEBUG"/>
> >         <formatter>
> >           .....
> > <logger category="org.ovirt.engine.core.bll">
> >         <level name="DEBUG"/>
> 
> ENGINE_JBOSS_ENGINE_ATTRS="autoflush=\"true\""
> ENGINE_JBOSS_LOGGING="<logger category=\"org.ovirt.engine.core.bll\"><level
> name=\"DEBUG\"/></logger>"

Sorry:

ENGINE_JBOSS_LOGGING_ENGINE_ATTRS="autoflush=\"true\""
ENGINE_JBOSS_LOGGING="<logger category=\"org.ovirt.engine.core.bll\"><level name=\"DEBUG\"/></logger>"

hmmm... autoflush="true" is by default (current), no need to have it more complex. Back to my initial suggestion, the following should be sufficient:

ENGINE_JBOSS_LOGGING="<logger category=\"org.ovirt.engine.core.bll\"><level name=\"DEBUG\"/></logger>"

oh... sorry for the noise... you meant the <level name="INFO"/> within the ENGINE, I think it can be DEBUG per default at handler as all loggers can be set as at least INFO.

OK, short talk with jiri, he would like this to be exposed to users, be more specific than what I recommended as a solution for the local problem that can be used by support if required.

Having specific solution means that if we want to control precise logging option we need to sync the packaging with the changes within the engine, update documentation and implementation as we go.

I do not believe that this worth the effort.

Based on comment 11 we will not handle it,
and closing as won't fix. If you wish  to provide
a solution, patches are welcomed.