Hi João,
I'm using the latest mbx as from https://github.com/shapeblue/mbx there is no
private fork/version that I'm using. I did a quick test against 4.19/main EL8
packages from latest main branch from today and they're deploying okay for me.
I'm using mbx on a NUC9 i7 based mini-pc server with Ubuntu 22.04 + KVM.
Regards.
From: João Jandre Paraquetti
Sent: Friday, May 26, 2023 20:04
To: dev@cloudstack.apache.org ;
us...@cloudstack.apache.org
Subject: Re: ACS upgrade to Log4J2 version 2.19
Hi Rohit,
> PR has issues with intermittent Github Actions failures (which
I'm not sure are due to the PR or generally - this needs to be
investigated and fixed). While simulator-based Github Actions
smoketests appear to pass, and perhaps the PR works in your
environment, it doesn't work with actual environments with both
BO/Trillian and mbx. In actual env, systemvms not starting and I
could reproduce Joao's volume issue, which doesn't happen with 4.18
pkgs using mbx or Trillian/BO (so I think the PR isn't stable yet).
I see Daan has also found and has reported other issues.
The issues reported by you happened to me even when using packages from
main. MBX has the same behavior with both packages (main and my PR).
Maybe you are using a different version of MBX that is not the one in
github?
> Since this is a rather large PR change, it would also require
some manual testing of the logs and upgrade tests and for the
community to commit efforts towards that. It's possible more runtime
issues are found with different hypervisors/storages, so it's
important the PR tests exhaustively all the supported hypervisors,
and at least NFS and local storages (scaleio, ceph, storpool, linbit
etc. would be great too). Due to this, this can potentially take
more time and effort to stablise it, and maybe far away to consider
merging.
The manual testing has already been done by at least 3 people. With
multiple hypervisors and plugins. As always, further testing is welcome.
About upgrading and supporting the community, I am happy to help review
PRs and point people in the right direction, I also can try my best to
respond questions in the ML regarding log4j2. As for the log4j2
configuration upgrade, the new configs will have the same names and same
paths as the old ones, this upgrade has already been tested. All that
users must do when installing the new packages is answer 'yes' when
questioned about upgrading the log4j config.
Best regards,
João Jandre (JoaoJandre)
On 26/05/2023 06:19, Rohit Yadav wrote:
> João, Daniel, Daan, All,
>
> I've reviewed and tested the PRhttps://github.com/apache/cloudstack/pull/7131
> using packages Daan uploaded onhttps://download.cloudstack.org/testing/7131/
> (thanks Daan!) and added my comment on the PR.
>
> PR has issues with intermittent Github Actions failures (which I'm not sure
> are due to the PR or generally - this needs to be investigated and fixed).
> While simulator-based Github Actions smoketests appear to pass, and perhaps
> the PR works in your environment, it doesn't work with actual environments
> with both BO/Trillian and mbx. In actual env, systemvms not starting and I
> could reproduce Joao's volume issue, which doesn't happen with 4.18 pkgs
> using mbx or Trillian/BO (so I think the PR isn't stable yet). I see Daan has
> also found and has reported other issues.
>
> Since this is a rather large PR change, it would also require some manual
> testing of the logs and upgrade tests and for the community to commit efforts
> towards that. It's possible more runtime issues are found with different
> hypervisors/storages, so it's important the PR tests exhaustively all the
> supported hypervisors, and at least NFS and local storages (scaleio, ceph,
> storpool, linbit etc. would be great too). Due to this, this can potentially
> take more time and effort to stablise it, and maybe far away to consider
> merging.
>
> We also need some plan on how we support users esp for upgrades and other
> developers in the community. Reflecting on this, here's what I propose we
> should do once the PR is ready for testing, passes testing and community
> guidelines for merging:
>
>* Figure out and document manual/semi/automated steps that users should
> take while upgrading to future ACS version which has this PR. For example,
> the packages post-install script could figure out a way wherein old log4j xml
> config is renamed/backed-up and new only is installed in a way that it
> continues to log in the same file/path so as not to disrupt a normal user's
> expectation of CloudStack logging (the log file paths and logging format).
>* We need an upgrade documentation PR as for admin users.
>* Anybody with a private plugin/integration would likely be impacted by
> them. But the authors can build support on dev@ ML and support them, esp
> post-merging
