New Log4j xml upon upgraded not warned as must have

[rohityadavcloud]

Minor issue - upon upgrading from 4.19 to 4.20 (RC3), my agent's logging got broken as when it asked me to replace the log4j xml or not I selected (N - no). However, later the logging wouldn't work. I could copy log4j xml from another host where I decided to use the new pkg (deb) provided log4j xml.

We need to document how logging/xml config should be migrated & used. Or prompt in future 4.20.1+ in the deb/rpm packages if possible

ISSUE TYPE

• Improvement Request

COMPONENT NAME

Package installation/upgrade

CLOUDSTACK VERSION

4.20 RC3

[JoaoJandre]

@rohityadavcloud I have added a section on the 4.20 docs (see apache/cloudstack-documentation#449 ) regarding the log4j2 XML file. Do you think that that's enough?

[DaanHoogland]

@rohityadavcloud @JoaoJandre is there a use case for not upgrading the log4j.xml? It reads to me like it should always be upgraded.

[JoaoJandre]

@rohityadavcloud @JoaoJandre is there a use case for not upgrading the log4j.xml? It reads to me like it should always be upgraded.

It should always be upgraded, otherwise the logging will not work, as @rohityadavcloud experienced.
However, we might not want to forcefully substitute the old file with a new one. The user might want to manually upgrade their file, if they have made changes to it, for example.
I think that having it on the release notes and having it be asked on install is enough. I'm not sure what else we should do.

[DaanHoogland]

@rohityadavcloud @JoaoJandre is there a use case for not upgrading the log4j.xml? It reads to me like it should always be upgraded.

It should always be upgraded, otherwise the logging will not work, as @rohityadavcloud experienced. However, we might not want to forcefully substitute the old file with a new one. The user might want to manually upgrade their file, if they have made changes to it, for example. I think that having it on the release notes and having it be asked on install is enough. I'm not sure what else we should do.

I think we can reverse the procedure;

• make a copy of the old file
• replace it
• document that the user needs to re-incorporate their changes

(no hard demand, but it seems better given Rohit's experience)

[rohityadavcloud]

I was hoping, at least on debian it will move/replace the old one. Of course I was able to address it. Closing it.