Re: [VOTE] Release Apache CloudStack CloudMonkey 6.3.0 - RC1

[Nicolas Vazquez]

+1 (binding)

Packages built from source tag: 6.3.0, tested different APIs and autocompletion 
fixes for this milestone

Regards,
Nicolas Vazquez


From: Daan Hoogland 
Date: Wednesday, 3 May 2023 at 07:06
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: Re: [VOTE] Release Apache CloudStack CloudMonkey 6.3.0 - RC1
+1 (binding),

monkey tested (no pun intended)
connected to different local and remote envs bot by restarting and set
profile commands.
tried different commands and command completions

Also trusting on Rohit's due diligence

On Wed, May 3, 2023 at 11:32 AM Rohit Yadav 
wrote:

> +1 (binding)
>
> The tarball/source and signatures are okay:
>
> # gpg --verify apache-cloudstack-cloudmonkey-6.3.0-src.tar.bz2.asc
> gpg: assuming signed data in
> 'apache-cloudstack-cloudmonkey-6.3.0-src.tar.bz2'
> gpg: Signature made Mon May  1 19:36:51 2023 IST
> gpg:using RSA key 4A64E2F46BBC136DD92D71FB5B7DEFE0508A4AD8
> gpg: Good signature from "Boris Stoyanov " [unknown]
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:  There is no indication that the signature belongs to the
> owner.
> Primary key fingerprint: 4A64 E2F4 6BBC 136D D92D  71FB 5B7D EFE0 508A 4AD8
>
> I was able to build cmk from the tarball source code and also tested the
> uploaded community/convinience binaries and checksum - LGTM.
>
> I also checked the md5 checksum for the binaries on the Github
> pre-release, they match the description on the pre-release:
>
> > md5 cmk.*
> MD5 (cmk.darwin.arm64) = 1e9768e47350da347e5dae9c84db60e7
> MD5 (cmk.darwin.x86-64) = 132b6e32bf24f5c4472c7db31a12c4b9
> MD5 (cmk.linux.arm32) = fc881649ff02c91eb28f0a83229125f2
> MD5 (cmk.linux.arm64) = 8dfc3b284ee12b7c2564b9cf1bb47cb8
> MD5 (cmk.linux.x86) = 6f0a0776fdd0acd010f919413937c33c
> MD5 (cmk.linux.x86-64) = 85616fd8c48648b353065878f78ae7d4
> MD5 (cmk.windows.x86-64.exe) = e0f726ce7ce518275dc4f8cad8e8bad3
> MD5 (cmk.windows.x86.exe) = b7e7109f6ab8c9899bb0c0635bd66a1c
>
> The version/build ID checks OK:
>
> On Mac OSX arm64:
> # ./cmk.darwin.arm64 -v
> Apache CloudStack  CloudMonkey 6.3.0 (build: 860771a,
> 2023-04-28T15:06:57+0300)
>
> On Ubuntu Linux 22.04 x86_64:
> # ./bin/cmk -v
> Apache CloudStack  CloudMonkey 6.3.0 (build: 860771a,
> 2023-04-28T15:06:55+0300)
>
> I performed basic API calls to list various resources and deploy VM [1]
> using the cmk CLI on darwin/arm64, both in interpreter mode and in a shell
> script. Tested against a local 4.17.2.0 env and also the community QA
> server;
>
> [1] cmd ref: deploy virtualmachine
> serviceofferingid=1be5e5c5-1a1e-4a61-b717-b19ba10579aa
> templateid=0392376b-ac6c-46cd-be15-48d8ea3ba175
> zoneid=c843ba49-21c3-4616-a3ff-07bb91db3a6b
> networkids=6d625e42-f1cc-4fe1-be95-a28256fc6df2
>
>
> Regards.
>
> 
> From: Boris Stoyanov 
> Sent: Monday, May 1, 2023 19:48
> To: dev@cloudstack.apache.org ;
> us...@cloudstack.apache.org 
> Subject: [VOTE] Release Apache CloudStack CloudMonkey 6.3.0 - RC1
>
> Hi All,
>
> I've created a v6.3.0 release of CloudMonkey, with the following
> artifacts up for a vote:
>
> Git Branch and commit SHA:
>
> https://github.com/apache/cloudstack-cloudmonkey/commit/860771ad1e2a759a8099a4dbeb264c342e3b9577
>
> Commit:
> 860771ad1e2a759a8099a4dbeb264c342e3b9577
>
> GitHub pre-release (for RC1 testing, contains changelog,
> artifacts/binaries to test, checksums/usage details):
> https://github.com/apache/cloudstack-cloudmonkey/releases/tag/6.3.0
>
> Source release (checksums and signatures are available at the same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/cloudmonkey-6.3.0/
>
>
> PGP release keys (signed using 4A64E2F46BBC136DD92D71FB5B7DEFE0508A4AD8)
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> The vote will be open until 5th May, 2023.
>
> For sanity in tallying the vote, can PMC members please be sure to
> indicate "(binding)" with their vote?
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and the reason why)
>
>
>
>
>
>
>
>

--
Daan

 

Re: [PROPOSE] ACS 4.18.1.0 release

[Nicolas Vazquez]

Great, thanks Wei for volunteering

Regards,
Nicolas Vazquez


From: Wei ZHOU 
Date: Thursday, 4 May 2023 at 05:34
To: dev@cloudstack.apache.org , users 

Subject: [PROPOSE] ACS 4.18.1.0 release
Hi all,

Currently CloudStack 4.18.0.0 is the latest LTS release. There are some
bugs and pull requests with 4.18.0.0 [1], including the fix for the upgrade
issue if users use MySQL 5.6 and 5.7.

I would like to propose the release of 4.18.1.0 and the timeline

- from now till the end of July (3 months): accept bug fixes and minor
improvements [2]
- first week in Aug: stablisation efforts, accept only blocker and critical
bug fixes.
- Aug: start cutting RCs, vote and finish release work.

I will push myself as the release manager (RM) of 4.18.1.0, if nobody
objects.
In case anyone wants to include a bug fix or a pull request in 4.18.1.0
milestone, please mention me (weizhouapache) on github.

[1] https://github.com/apache/cloudstack/milestone/27
[2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS


Any suggestions ?

Kind regards,
Wei

 

Re: [PROPOSE] ACS 4.18.1.0 release

[Daan Hoogland]

+1, you have my support @weiz...@apache.org 

On Thu, 4 May 2023, 10:02 Rohit Yadav,  wrote:

> +1
>
> Thanks for volunteering Wei, yes our community absolutely will benefits
> with a 4.18.1.0 maintenance release!
>
>
> Regards.
>
> 
> From: Wei ZHOU 
> Sent: Thursday, May 4, 2023 14:04
> To: dev@cloudstack.apache.org ; users <
> us...@cloudstack.apache.org>
> Subject: [PROPOSE] ACS 4.18.1.0 release
>
> Hi all,
>
> Currently CloudStack 4.18.0.0 is the latest LTS release. There are some
> bugs and pull requests with 4.18.0.0 [1], including the fix for the upgrade
> issue if users use MySQL 5.6 and 5.7.
>
> I would like to propose the release of 4.18.1.0 and the timeline
>
> - from now till the end of July (3 months): accept bug fixes and minor
> improvements [2]
> - first week in Aug: stablisation efforts, accept only blocker and critical
> bug fixes.
> - Aug: start cutting RCs, vote and finish release work.
>
> I will push myself as the release manager (RM) of 4.18.1.0, if nobody
> objects.
> In case anyone wants to include a bug fix or a pull request in 4.18.1.0
> milestone, please mention me (weizhouapache) on github.
>
> [1] https://github.com/apache/cloudstack/milestone/27
> [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
>
>
> Any suggestions ?
>
> Kind regards,
> Wei
>
>
>
>

Re: ANNOUNCEMENT: CloudStack Collaboration Conference

[Rohit Yadav]

Excellent news and venue!



Regards.


From: Wei ZHOU 
Sent: Tuesday, May 2, 2023 19:39
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org ; Apache 
CloudStack Marketing 
Subject: Re: ANNOUNCEMENT: CloudStack Collaboration Conference

Great news.

Thanks Ivet and DIMSI for the organization.

Looking forward to the event.

-Wei

On Tuesday, 2 May 2023, Ivet Petrova 
mailto:ivet.petr...@shapeblue.com>> wrote:
Hello all,

I am delighted to announce that this year’s CloudStack Collaboration Conference 
will happen on November 23-24th in Paris in Holiday Inn Paris - Porte De Clichy.
The location is already announced on the website of the event: 
https://www.cloudstackcollab.org/
In a couple of weeks we will open the registration for the event and the CFP.
About the Venue: Holiday Inn Paris - Porte De 
Clichy
If you plan to join and want to stay in the hotel, where the event will be, 
please ensure you do an early booking.
IMPORTANT: Organising a major community event in Paris is quite hard and costly 
task. I will be happy if there are more volunteers to help in the organisation 
this year. + We really look forward for as many as possible sponsors, so that 
we can organise a stunning event and cover all of the costs. As before, the 
event will be hybrid and we will live stream it. So I am open to have a chat 
with all organisations, who want to support the event.
Here we come, Paris!

Kind regards,





 

Re: [PROPOSE] ACS 4.18.1.0 release

[Rohit Yadav]

+1

Thanks for volunteering Wei, yes our community absolutely will benefits with a 
4.18.1.0 maintenance release!


Regards.


From: Wei ZHOU 
Sent: Thursday, May 4, 2023 14:04
To: dev@cloudstack.apache.org ; users 

Subject: [PROPOSE] ACS 4.18.1.0 release

Hi all,

Currently CloudStack 4.18.0.0 is the latest LTS release. There are some
bugs and pull requests with 4.18.0.0 [1], including the fix for the upgrade
issue if users use MySQL 5.6 and 5.7.

I would like to propose the release of 4.18.1.0 and the timeline

- from now till the end of July (3 months): accept bug fixes and minor
improvements [2]
- first week in Aug: stablisation efforts, accept only blocker and critical
bug fixes.
- Aug: start cutting RCs, vote and finish release work.

I will push myself as the release manager (RM) of 4.18.1.0, if nobody
objects.
In case anyone wants to include a bug fix or a pull request in 4.18.1.0
milestone, please mention me (weizhouapache) on github.

[1] https://github.com/apache/cloudstack/milestone/27
[2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS


Any suggestions ?

Kind regards,
Wei

 

[PROPOSE] ACS 4.18.1.0 release

[Wei ZHOU]

Hi all,

Currently CloudStack 4.18.0.0 is the latest LTS release. There are some
bugs and pull requests with 4.18.0.0 [1], including the fix for the upgrade
issue if users use MySQL 5.6 and 5.7.

I would like to propose the release of 4.18.1.0 and the timeline

- from now till the end of July (3 months): accept bug fixes and minor
improvements [2]
- first week in Aug: stablisation efforts, accept only blocker and critical
bug fixes.
- Aug: start cutting RCs, vote and finish release work.

I will push myself as the release manager (RM) of 4.18.1.0, if nobody
objects.
In case anyone wants to include a bug fix or a pull request in 4.18.1.0
milestone, please mention me (weizhouapache) on github.

[1] https://github.com/apache/cloudstack/milestone/27
[2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS


Any suggestions ?

Kind regards,
Wei

Re: ACS upgrade to Log4J2 version 2.19

[Rohit Yadav]

Daniel,

On your remarks;

  *   The currently logging process indeed allows us to make changes to the log 
config xml which is read by the framework to affect what is logged, without 
restarting say the management server, kvm agent or the ssvm/cpvm agents. Few of 
my colleagues have confirmed this works already. I'm not sure about any other 
features (or lack of them).

  *   You're right about Reload4j's project statement to not add major changes, 
however, they state they'll do performance improvements, enhancements, and 
(security) fixes. I think this meets the requirements of having a stable, 
reliable logging library. But you're right about the general innovation 
argument.

That said if we've features we require, then I would look at (a) can there be a 
central library framework/utility allowing users to choose what library they 
want to use, or (b) let's just agree and move to the proposed log4j2.x if there 
are clear advantages.

From what I've learned so far I don't see such clear advantages for the use 
cases I'm thinking or I've considered. I would be wrong by a mile, but happy to 
hear what others think.

  *   On testing the PR, those of us with access can certainly help as we help 
on all community PRs to review and help test. Pl go ahead and ask any 
specifics, I'm sure we'd be happy to assist. I see a few contributors with 
access are already helping.

Another option the authors have is to try and build the rpm and deb packages 
themselves (we've documentation I think, and container images that BO/Trilian 
uses here https://hub.docker.com/u/shapeblue). With such packages, the authors 
can at least test basic CloudStack installation, setup and zone deployment, VM, 
volume lifecycles. They may also try to deploy such env if packages are 
available and run smoketests using mbx which is a lite-version of BO/Trillian 
CI system, or that may be done even manually (say with KVM in a VM?).

  *   We shouldn't favour a particular pull request 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 cons, see how to reduce the impact, build support in the 
community, define and agree on a plan and then execute with the community. The 
right path can be hard and long.

We've in fact waited long time (sometimes a year or more) on many such 
large-impact initiatives, for example getting the ant-design/vue-based UI to 
deprecate the legacy UI probably took about two years, off recently for the 
vue3 upgrade PR we had to wait for 2-3 major releases, the tungsten support PR 
is another one 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 unavoidable and painful to 
stakeholders, but in hindsight they were the right approaches compliant to ASF, 
the community did the right thing for themselves.


Regards.


From: Daniel Salvador 
Sent: Thursday, May 4, 2023 02:28
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: Re: ACS upgrade to Log4J2 version 2.19

Hi all,

Nux, thanks for the advice on communication, it makes perfect sense.

Regarding Rohit's points, these are my thoughts about them:

- Reload4J is a project with the goal of fixing pressing security issues
for 1.2.17 and its community does not seem to have the goal of adding new
features, as its own documentation claims (it is not a demerit of the
project, it is just a characteristic of it). This holds us to a limited
technology and does not allow us to make progress in this area of the
project. We are 10 years behind logging technologies and the more we wait,
the harder it will be to advance.

- All the features João has mentioned will facilitate the troubleshooting
and the coding process. Based on my experience, the most important points
of them in our current context are (i) the automatic reload of
configurations, which allows us to change the configurations without having
to restart the service and losing the context for the troubleshooting, and
(ii) the improvements on the code writing that comes with its features
(lambda support, message support, and others).

- With respect to the side effects of the patch, indeed, it is expected to
have conflicts on the pull requests. However, most of them (if not all)
will be related to the logging package import and logger renaming, as Rohit
have pointed out; thus, the major work would be renaming the loggers to the
standardized name. Perhaps João could share with us the script he used to
standardize the loggers names, as he already did with the other scripts he
used (which are in the PR description).

- Almost daily, CloudStack receives pull requests; this way, if we wait for
the PRs to be merged