All,
The latest news I heard from the reload4j project is that they are now
sponsored by the Sovereign Tech Fund (STF) among other backers [1] so I don't
see any support, maintenance, longevity risk for the CloudStack project to
continue using reload4j:
https://twitter.com/qos_ch/status/1657069740341198881
Considering all the facts, I don't think there is any urgency or technical
requirement for us to switch our current logging library.
However, I also don't object to the proposed effort to upgrade CloudStack to
log4j 2.x as long as;
* all risks are have been considered and all efforts are made to reduce the
impact (for example, help merge as many outstanding PRs as possible before
merging this, possibly merge the PR early in the release cycle once consensus
is established)
* a plan is shared with the community as to when and how we migrate to
log4j 2.x, and any manual upgrade/migration steps are documented; a notice may
be released on the project blog or in the next release notes
* it meets the community guidelines of passing reviews, CI/build tests (esp
smoketests across all supported distros and hypervisors), and wrt release
perhaps also the upgrade tests
The PR's current approach of replacing reload4j with log4j 2.x does not reduce
the impact on the community in the future if there is another breaking library
change. I like Daan's suggestion of having a log-agnostic logging utility if
it's possible to accommodate.
Regards.
From: Daniel Salvador
Sent: Thursday, May 11, 2023 05:43
To: us...@cloudstack.apache.org
Cc: dev@cloudstack.apache.org
Subject: Re: ACS upgrade to Log4J2 version 2.19
Daan,
IMHO, proxying libraries would bring us more disadvantages than benefits.
If we define that the standard is to proxy libraries such as Utils, Log4J,
and others, we would have to proxy all of them (even Spring); it would
require a huge effort (way more than this work with Log4j) to introduce and
maintain those proxies. Also, ACS already is a complex system to work;
proxying libraries would add one more layer of complexity to the platform
(and one more point of failure); thus, making it difficult for new
contributors to join the community.
The community already put a lot of effort into the Log4J2 upgrade. The PR
being discussed in this thread is ready for merge (besides the conflicts
that the author is resolving as soon as they appear), it has been tested
(it could benefit from more testing though) with a variety of setups and
use cases, and the impact on conflicts is minimal (giving its size and
nature); therefore, along with what I pointed out, I do not think proxying
libraries would be a good approach.
Furthermore, to conclude. If the community seems to count on support of
both users and other devs, and we have already done quite an extensive test
round, what else are we missing to move along with that PR? Is any of the
merging criteria missing to move on with it?
Best regards,
Daniel Salvador (gutoveronezi)
On Tue, May 9, 2023 at 1:52 PM Daan Hoogland
wrote:
> Rohit, Daniel,
>
> Let me weigh in a bit. I held back about this as I have discussed this in
> the past a lot in different settings and do not want to take sides. My
> personal motivation for either reload4j or log4j2 are slim but I can see
> that people might want to lean to either. For this reason I want to bring
> up another pet preference of mine:
>
> I think we should proxy each and every external library we use with our own
> packages. This means not even using something like slf4j but implement our
> own framework and let people choose either on package or on deploytime what
> to use, with a reasonable default of course.
> At the moment I would lean towards log4j2 as the default but I do not want
> my clients to have to use that as I know some of them will blame me for
> extra night shifts if we do.
>
> This pet preference is valid for more than logging but is very applicable
> on the subject.
>
> This will require some extra effort, so feel free to push back but I think
> it will be worth it.
>
> that all said the standardisation of the calling side of things is going to
> be a pain but should be done as well. (imnsho)
>
> regards,
>
>
> On Sat, May 6, 2023 at 3:31 AM Daniel Salvador
> wrote:
>
> > Thanks, Rohit for the reply
> >
> > Not only the author, but me and other colleagues from the community can
> > build DEB and RPM packages (commands [1] and [2]). We already did, and
> the
> > process to build RPM and DEB works just fine.
> >
> > Also, basic CloudStack installation, setup and zone deployment, VM and
> > volume lifecycles with KVM and VMware, and so on, have already been
> tested
> > and that was reported on the PR and this thread. The problem here is that
> > blueorangutan is failing and it is a black box; therefore, the author
> does
> > not know what is happening inside it.
> >
> > The conflicts that might happen in other PRs is mostly renaming the
> >
