based mini-pc server with Ubuntu 22.04 + KVM.
Regards.
From: João Jandre Paraquetti
Sent: Friday, May 26, 2023 20:04
To: d...@cloudstack.apache.org ;
users@cloudstack.apache.org
Subject: Re: ACS upgrade to Log4J2 version 2.19
Hi Rohit,
> PR has issues w
enough for merging; I think
the vote was a bit early and unnecessary. I encourage authors and the community
to continue the discussions here and stabilise the PR.
Thanks and regards.
From: Daan Hoogland
Sent: Wednesday, May 17, 2023 18:16
To:d...@cloudstack
rly and unnecessary. I encourage authors and the community
to continue the discussions here and stabilise the PR.
Thanks and regards.
From: Daan Hoogland
Sent: Wednesday, May 17, 2023 18:16
To: d...@cloudstack.apache.org
Cc: users@cloudstack.apache.org
Subj
uest over others, or
> for
> > > > that matter one library vs another; however, as with anything that
> > > impacts
> > > > the community, potentially cause overhead/work, the community must
> try
> > to
> > > > review the facts, pros, and
e. 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: users@cloudstack.apache.org
Cc: d...@cloudstack.apache.org
Subject: Re: ACS upg
ible to accommodate.
Regards.
From: Daniel Salvador
Sent: Thursday, May 11, 2023 05:43
To: users@cloudstack.apache.org
Cc: d...@cloudstack.apache.org
Subject: Re: ACS upgrade to Log4J2 version 2.19
Daan,
IMHO, proxying libraries would bring us more disadvantages than b
The changes are huge so reviewing 100% is not possible, are the scope
> > > > changes strictly logging replacement or there are other changes?
> > > >
> > > > What is the current state of the PR, is it ready? Has anybody looked
> at
> > > > the
I can think off, and initiatives such as
> getting
> > the go-sdk and terraform plugin donated in the community took long and
> > painful months to get them done. In all these cases, the issue of having
> > daily conflicts or building consensus, or having to wait long term was
> >
In all these cases, the issue of having
> daily conflicts or building consensus, or having to wait long term was
> unavoidable and painful to stakeholders, but in hindsight they were the
> right approaches compliant to ASF, the community did the right thing for
> themselves.
>
>
>
have
> shown that logback's AsyncAppender is both simpler and significantly
> faster.
>
> 2) at least one downstream appender is slow
>
> In which case, the very large buffer will slowly fill up, possibly
> exhausting available memory. More importantly, in case the application
gt; 2) at least one downstream appender is slow
>
> In which case, the very large buffer will slowly fill up, possibly
> exhausting available memory. More importantly, in case the application
> is stopped, this will result in large amount of logging data to be lost,
> which is far from
Regards.
From: Abhishek Kumar
Sent: Wednesday, May 3, 2023 15:16
To: users@cloudstack.apache.org
Cc: d...@cloudstack.apache.org
Subject: Re: ACS upgrade to Log4J2 version 2.19
Hi Daniel,
It was just my opinion it is based on the reasons that it is something tha
Hi Daniel,
It was just my opinion it is based on the reasons that it is something that
we haven't seen any request in the community before and it will create some
challenges for the releases, forward-merging bug-fixes and also for any
existing integrations that users might be having.
To be specifi
Hello,
I'm +1 on implementing this change, the importance has already been well
explained. Improving any process has a degree of difficulty, but it can be
a great improvement and help in future versions.
As there are volunteers for this improvement, this PR is important for the
evolution of Cloud
Hi Daniel and all,
With my PMC hat on, I'm +1 on implementing this PR. "The show must go
on" as they say.
I also see no reason this should wait for 5.0, there is nothing special
about v5 that I know of, it's just a number.
The PR is indeed quite large and it has the potential to "inconvenie
Abhishek,
I do not see why it would be a 5.0 change. Also, ACS 5.0 is a discussion
the community has been having for a long time from now and is something we
are too far away to achieve consensus.
The patch is important to enable further development for the log management
on ACS and facilitate ev
Great work.
Though I feel this is a 5.0 change. I agree with Wei that this would create
too much overhead for upcoming releases. 4.18 was pushed ahead a few months
and we may end up on a similar path.
Also, reload4j is still actively maintained so I don't think this is urgent.
Regards,
Abhishek
O
Hello guys,
Thanks, Felipe Rossi for the reply, operators are a vital part of the
community and your opinions are of the greatest importance to the project's
advancement.
I already did a lot of tests with the patch and I think we are in a good
way to place it. I am +1 on it.
Regarding Wei's conc
Hi Joao,
Thanks for bringing this to our attention.
I am +1 with log4j 2.x. It is not urgent to me, as we are currently using
reload4j which is still well maintained:
https://mvnrepository.com/artifact/ch.qos.reload4j/reload4j
My concern is, you have made a huge amount of rename of variables, fo
Hello everyone,
This upgrade is fundamental, because log4j is deprecated, not possible to
make new updates/upgrades.
with log4j2 we can expand, receive new upgrades/updates, with maintenance
of a secure environment and evolution.
the importance of this is not questionable.
Att / Regards
Felipe
In PR #7131 (https://github.com/apache/cloudstack/pull/7131) I have
proposed to normalize ACS's loggers, and more importantly, upgrade the
library log4j to log4j2 version 2.19.
Log4j2 has a lot of features that could offer benefits to ACS:
* Async Loggers - performance similar to logging swit
21 matches
Mail list logo
