[DISCUSSION] Management of the database's "VIEW"s

[Daniel Augusto Veronezi Salvador]

Hello guys,

I would like to open a discussion on our current management of the database's 
"VIEW"s.

Currently, we have to look at the changes in the previous "schema" files and replicate the whole "CREATE 
VIEW" command in the current "schema" file, modifying what we need (adding/removing columns, and so on). This 
process makes the changes in a "VIEW" to be distributed through several files, increasing the number of lines modified 
for simple changes (e.g.: for adding a single field to the "VIEW" result we need to replicate the whole command); thus, 
making it difficult to maintain and track.

With that in mind, I had some ideas of how we can improve this process. The proposal is: instead of 
adding the changes to the current "schema" file, we create unique files for each 
"VIEW" and manage them; more detailed:
1. under the directory "db", where the "schema" files are, we would create a 
sub-directory called "views";
2. in the sub-directory "views", we would create a file for each "VIEW", named with the 
"VIEW" name (for instance, "cloud.network_offering_view.sql");
3. in the "VIEW" file, we would put the "DROP VIEW" command, followed by the "CREATE VIEW" command, 
just as we do in the "schema" file; for instance, the content of file "cloud.network_offering_view.sql" would 
be:

```
DROP VIEW IF EXISTS `cloud`.`network_offering_view`;

CREATE VIEW `cloud`.`network_offering_view` AS
SELECT
`network_offerings`.`id` AS `id`,
`network_offerings`.`uuid` AS `uuid`,
`network_offerings`.`name` AS `name`,

```

4. then, after each version upgrade, in Java we execute all the files in the sub-directory 
"views"; this way, if a "VIEW" changed, it would be recreated with the new 
changes; otherwise, it would be only recreated as is;

That would allow us to easily track "VIEW" modifications, as we would just change the "VIEW" 
declaration in the same file, instead of re-declaring the whole "VIEW" in a different file; and we would have 
a better history of the changes. Also, we would not need to migrate all "VIEW"s right away; we could migrate 
as we change them.

Please, let me know your thoughts about the proposal.

Best regards,
Daniel Salvador (gutoveronezi)

Re: [DISCUSS] Github Discussions for CloudStack?

[Daniel Augusto Veronezi Salvador]

Hello all,

The feature GitHub Discussions seems very interesting; I think it worth 
enabling it and trying it (+1).


I just have one doubt: would we forward Discussions' updates to the 
mailing lists?


Best regards,
Daniel Salvador (gutoveronezi)

On 14/12/2022 06:07, Rohit Yadav wrote:

All,

In the past, we had moved away from JIRA and ReviewBoard to Github as it 
provided a single platform for both the user and the dev community to 
collaborate on issues/requests and code changes (pull requests). We later 
organically started using Github for release milestones/triaging, recently 
projects. For sub-projects such as cloudstack-cloudmonkey, 
cloudstack-terraform-provider etc we also use the wiki features. More recently 
we're not advised to move to Github actions from Travis CI by ASF infra.

Off lately, several user-related discussions and questions that we would have 
expected on the users ML are finding ways in Github issues, which aren't issues 
per se but questions, and discussions. Should we explore, enable and try Github 
Discussions [1] for CloudStack repos?

Several Apache projects have enabled Github Discussions [1], for example:
https://github.com/apache/couchdb/discussions
https://github.com/apache/apisix/discussions
https://github.com/apache/shardingsphere/discussions
https://github.com/apache/streampipes/discussions
https://github.com/apache/pulsar/discussions
https://github.com/apache/airflow/discussions
https://github.com/apache/dolphinscheduler/discussions
https://github.com/apache/inlong/discussions
https://github.com/apache/doris/discussions
https://github.com/apache/arrow-datafusion/discussions
https://github.com/apache/superset/discussions

[1] https://github.com/features/discussions


Regards.

  

Re: VMs HA not working with Ceph

[Daniel Augusto Veronezi Salvador]

Hello, Ranjit and Nux

About the second point in the last message: there is no need to edit the file 
'kvmheartbeat.sh' to avoid restarting the host. PR #4586[¹], released in 
4.16.0, introduced the property 
'reboot.host.and.alert.management.on.heartbeat.timeout' in 'agent.properties'; 
if true (default) it will reboot the host if something goes wrong with the 
heartbeat; on the other hand, if set to false, it will not reboot the host. 
After changing the properties, it is necessary to restart the agent service.

Best regards,
Daniel Salvador (gutoveronezi)

[¹]https://github.com/apache/cloudstack/pull/4586  


On 05/12/2022 12:38, Nux wrote:

Hello,

For HA to work you need to:
1 - add a service offering with "HA" box enabled
2 - you need to have some NFS storage for the heartbeat/fencing 
mechanism - you don't need to use it for VMs, but it needs to be 
present and it needs to be super reliable or hypervisors might reboot 
if they see it goes away - this behaviour can be customised if you 
want to (and know what you are doing):
https://github.com/apache/cloudstack/blob/a63b2aba7aa3948f78d280a356c550c6638a137b/scripts/vm/hypervisor/kvm/kvmheartbeat.sh#L162 



HTH

---
Nux
www.nux.ro

On 2022-12-02 07:02, Ranjit Jadhav wrote:

Hello Guys,

We are also struggling with this HA thing any guidance will be highly
appreciated.

Regards,
Ranjit

On Thu, 1 Dec 2022 at 20:50, pspa...@hotmail.com 
wrote:


Hi,
I have build new infra with Ceph storage everything working well.
But VMs HA not working. Can anyone guide me.

Regards Pradeep Kumar

Re: [ANNOUNCE] Next PMC Chair & VP Apache CloudStack Project - Simon Weller

[Daniel Augusto Veronezi Salvador]

Thank you, Gabriel, for your great work and congratulations to Simon!

Best regards,
Daniel Salvador

On 17/03/2022 09:03, Paul Angus wrote:

Yes,

Same from me, thank you Gabriel, and congratulations Simon.

Kind Regards


Paul Angus

-Original Message-
From: Suresh Kumar Anaparti 
Sent: Thursday, March 17, 2022 11:26 AM
To: dev ; us...@cloudstack.apache.org
Cc:  
Subject: Re: [ANNOUNCE] Next PMC Chair & VP Apache CloudStack Project - Simon 
Weller

Congratulations Simon!

Thank you Gabriel, for your work.

Regards,
Suresh

On Thu, Mar 17, 2022 at 4:27 PM Rohit Yadav  wrote:

Congratulations Simon! And thank you Gabriel.

Regards.

On Thu, Mar 17, 2022 at 3:25 PM Gabriel Beims Bräscher
 wrote:

Hello, all CloudStack community!

It gives me great pleasure to announce that the ASF board last night
accepted our PMC's nomination of Simon Weller as the next PMC Chair
/ VP of the Apache CloudStack project.

I would like to thank everyone for the support I've received over the past year.
It was a great honor being the PMC Chair of this amazing project/community!

To Simon, my sincere congratulations, and I wish you success in the new role!
Very well deserved!

Please join me in congratulating Simon, the CloudStack PMC Chair / VP.

Best Regards,
Gabriel Bräscher.

Re: [VOTE] CentOS 7 KVM binaries

[Daniel Augusto Veronezi Salvador]

Apologies, Wei, I used the wrong term, it will be a recommendation, not 
a requirement.


On 04/03/2022 10:44, Wei ZHOU wrote:

Hi Daniel,

`qemu-kvm-ev` should be a recommendation, not a requirement on CentOS 7.
If it is a requirement, I am -1 on it as well.

-Wei

On Fri, 4 Mar 2022 at 13:58, Daniel Augusto Veronezi Salvador <
dvsalvador...@gmail.com> wrote:


Thanks, Rohit, for the reply.

Although it emerged from the PR, the discussion[¹] and voting was not
about the PR per se, but about considering adding *qemu-kvm-ev* as a
requirement for deploying ACS + KVM + CentOS 7. Apologies if it wasn't
very clear.

Solutions for PR 5297[²] and others that may come can be discussed in
their history line. The changes regarding this voting will be limited to
the documentation:
- On CloudStack's Installation Guide > Host KVM Installation[³], we add
a section guiding users to install the qemu-kvm-ev binaries, if they are
using CentOS 7.
- The packages that we will guide users to install will be the latest
provided by the official CentOS site[⁴] (the current latest version is
'2.12.0-44.1.el7_8.1.x86_64'.

With that said and based on last Rohit's reply, could I ask Nicolas and
Paul to review, make clear or withdraw their votes?

Best Regards,
Daniel Salvador


[¹] https://lists.apache.org/thread/z7s0774n72v4o9dnl140wvm030bxovjd
[²] https://github.com/apache/cloudstack/pull/5297
[³]

http://docs.cloudstack.apache.org/en/latest/installguide/hypervisor/kvm.html
[⁴] http://mirror.centos.org/centos-7/7/virt/x86_64/kvm-common/Packages/q/

On 04/03/2022 07:02, Rohit Yadav wrote:

Thanks for sharing your findings Nicolas. I'll base my vote on that.

Considering the vote is based on:
"- On CloudStack's Installation Guide > Host KVM Installation[²], we add

a

section guiding users to install the qemu-kvm-ev binaries, if they are
using CentOS 7.
- The packages that we will guide users to install will be the latest
provided by the official CentOS site[³] (the current latest version is
'2.12.0-44.1.el7_8.1.x86_64')."

+1 (binding) to doc changes limited to CentOS7 on using qemu-kvm-ev.

It's worth noting that qemu-kvm-ev (the -ev releases) isn't available for
el8 anymore? This may need double-checking as I couldn't find them on first
attempt or also search via yum/dnf [1]. We need at some point revisit the
QIG, add QIG for Ubuntu 20.04/22.04 (soon) and EL8 (rocky/alma/rhel8).

I would see the PR as a separate thing than this vote and I don't see

why Daniel's PR can't be accepted if he addresses the comments, with the
following suggested guidance and checklist:

*   The vote is just for docs and shouldn't be used to justify the

removal or regression of stock qemu support in el7/centos7.

*   Please fix the regression found in Nicolas's testing and address

other outstanding comments on the PR.

*   Regression test via smoketests in addition to any manual tests

can ensure it works for following environments:

   *   CentOS7 with stock qemu
   *   CentOS7 with qemu-kvm-ev
   *   CentOS8 with stock qemu
   *   Test Ubuntu 18.04/20.04 and OpenSUSE kvm env
   *   Misc: Since the PR changes are around storage/snapshot, we

should try to cover for local storage, nfs/qcow2, ceph/rbd (and
scaleio/raw) etc.

[1] Here's testing on a rocky8 instance:

[root@5c0edd1a88c0 /]# yum install centos-release-qemu-ev
Last metadata expiration check: 0:03:47 ago on Fri Mar  4 09:42:27 2022.
No match for argument: centos-release-qemu-ev
Error: Unable to find a match: centos-release-qemu-ev
[root@5c0edd1a88c0 /]# yum search qemu-ev
Last metadata expiration check: 0:05:09 ago on Fri Mar  4 09:42:27 2022.
No matches found.
[root@5c0edd1a88c0 /]# yum install qemu-img
Last metadata expiration check: 0:03:52 ago on Fri Mar  4 09:42:27 2022.
Dependencies resolved.


===

   Package   ArchitectureVersion

   Repository  Size
===

Installing:
   qemu-img  x86_64

15:4.2.0-59.module+el8.5.0+726+ce09ee88.1  appstream
   1.1 M


[2] @virt installation output (for versions reference) on rocky 8:

[root@5c0edd1a88c0 /]# dnf install @virt
Last metadata expiration check: 0:08:04 ago on Fri Mar  4 09:42:27 2022.
Dependencies resolved.


===

   Package   Arch  Version

 RepositorySize
=

Re: [VOTE] CentOS 7 KVM binaries

[Daniel Augusto Veronezi Salvador]

he concerns on the thread I have tested PR 5297 on CentOS 7 with stock 
qemu-kvm binaries to reevaluate my vote. I found only one regression around 
snapshots: taking volume snapshots for running VMs does not work anymore as 
qemu complains with error: Operation not supported: live disk snapshot not 
supported with this QEMU binary.

I agree with Paul and Rohit in this case as a drop of support for users on 
CentOS 7 with stock qemu-kvm, so my vote will be -1 in this case. But would be 
+1 if we can fix the regression for this specific case as the rest of the 
operations are working fine.

Regards,
Nicolas Vazquez


From: Rohit Yadav 
Date: Wednesday, 2 March 2022 at 11:06
To: dev@cloudstack.apache.org 
Subject: Re: [VOTE] CentOS 7 KVM binaries
Gabriel, Daniel, the pull request (code change) is new information for me 
https://github.com/apache/cloudstack/pull/5297

There's also no rule or guidance that people can't discuss on a voting thread, I find the 
terms used to refer to that "polluting" derogatory. The vote also did not 
mention the PR and its implications, I'm sure most people on the thread have voted only 
on doc changes. Thanks Gabriel to sharing the background, it also explains what led 
Daniel to start the vote.

Daniel, on the logistics of voting you may want to read the project bylaws and 
get familiar with the terms.

All, I'll need to find some time and then get back to this thread after 
reviewing pros and cons of the PR and its implications after some due 
diligence. Alternatively, I'm happy if some other PMC can do the due diligence, 
I'll then add my vote based on PMC findings.

Regards.

From: Daniel Augusto Veronezi Salvador 
Sent: Wednesday, March 2, 2022 6:00:51 PM
To: dev@cloudstack.apache.org 
Subject: Re: [VOTE] CentOS 7 KVM binaries

@Gabriel has summarized everything very well.

This proposal only adds a requirement (makes it clear) in our
documentation for KVM + CentOS 7 (please, refer to the discussion
thread[¹] to understand why it is necessary), which is what everybody
(according to the discussion we had in the mailing list) is already
applying in production environments. Therefore, we would only make this
requirement clear to everybody, which would in turn enable us to move
forward with KVM improvements (such as my PR that improves the snapshot
process[²]). It (the discussion we had) never addressed dropping support
for CentOS 7.

Regarding Rohit's comment ("However, assuming Daniel has followed the
bylaws and is suggesting this as a technical change that removes support
in source code or releases..."), I never suggested a drop of support for
CentOS 7. I don't know how that conclusion was derived.

To emphasize, this proposal do not address dropping support for CentOS
7. Please, review the discussion thread[¹] and the proposal and
reconsider your votes.

Best regards,
Daniel Salvador


[¹] https://lists.apache.org/thread/z7s0774n72v4o9dnl140wvm030bxovjd
[²] https://github.com/apache/cloudstack/pull/5297

On 02/03/2022 06:47, Gabriel Bräscher wrote:

I don`t want to "pollute" the vote thread, as we should keep discussions on
the proper thread (Discussion here [1]).
However, we are already in such a situation. I hope that I can add some
context and clarify a few things.

@Daniel, please correct me if I misunderstood anything or my raised points
are not aligned with the respective Discussion and Vote threads.
Here goes my point of view regarding.
1. Why this is a technical vote:
1.1 The PR [2] is not moving forward due to the fact that CentOS stock Qemu
does not support the feature added;
1.2 it will impact on code being accepted in case of "+1" or blocked in
case the vote does not pass;
1.3 If this vote does pass, we need to change the PRs tests by adding
"qemu-kvm-ev" package in Marvin CentOS7 test environments.

2. Why I don't think this is a drop of support:
2.1 From what I understood, the proposal does not state that CloudStack
will officially drop support for CentOS7 "stock" packages;
2.2 those running CentOS7 WITHOUT "qemu-kvm-ev" packages already are not
able to perform some actions and they will never be with the current
"stock" packages;
2.3 there will be no "backward" compatibility issues for them, as they are
still not able to perform such operations.
2.4 those running CentOS7 WITHOUT "qemu-kvm-ev" will remain capable of
doing what their distro offers support.

3. Why this vote is relevant for MOST of the community
3.1 Those running Ubuntu or CentOS7 WITH "qemu-kvm-ev" will be able to have
critical and relevant features as users will be able to follow the
instructions on documentation and the PRs blocked will finally be able to
be merged;
3.2 documentation will be clear and help users to make their own decision
and take any risks into account.

I want to stress how relevant this

Re: [VOTE] CentOS 7 KVM binaries

[Daniel Augusto Veronezi Salvador]

OS 7 KVM binaries

oh wait, is there any word saying removing the  support for centos7 with
stock qemu ?

-Wei

On Wed, 2 Mar 2022 at 07:38, Rohit Yadav 
wrote:


I had assumed this was a non-technical discussion/vote where the
changes are made in docs on suggested changes to how CloudStack is
deployed and used with CentOS7. I assumed this will follow as a doc PR

to the QIG.

Changes to docs aren't normally considered technical as per our
project bylaws as they don't impact changes in source code or
releases. Three different PMCs have already advised on this thread
that voting isn't mandatory for this.

However, assuming Daniel has followed the bylaws and is suggesting
this as a technical change that removes support in source code or
releases, then I oppose such a change.

-1 (binding/veto) if we're going to technically remove support for
centos7 with stock qemu, that is in source code and
packaging/releases. CentOS7 will EOL until 2024 and stock support should

be supported until then.

Regards.





From: Daniel Augusto Veronezi Salvador 
Sent: Wednesday, March 2, 2022 2:31:21 AM
To: dev@cloudstack.apache.org 
Subject: Re: [VOTE] CentOS 7 KVM binaries

Rohit,

As we are deciding a requirement for deploying ACS + KVM + CentOS 7, I
see it as an important technical decision, that is why I started the
voting thread. The discussion was made via another thread[¹];
therefore, this vote was created with the intention to summarize the
discussion we had and then to officially approve (or not approve) the

idea discussed.

Finally, to emphasize, this is the voting thread, intended to reflect
the decision we seem to have agreed upon in the other thread[¹]. I
would kindly ask to avoid polluting this thread with discussions not
related to the voting itself. Furthermore, as already stated, there is
a consensus in the discussion thread; therefore, there is no harm in
giving a +1 here.

Best regards,
Daniel Salvador

[¹] https://lists.apache.org/thread/z7s0774n72v4o9dnl140wvm030bxovjd

On 01/03/2022 16:56, Rohit Yadav wrote:

(phone issue sent draft accidentally)... where consensus is built

without opposition. Therefore this vote thread isn't necessary.

Refer to project bylaws https://cloudstack.apache.org/bylaws.html

Regards.

From: Daniel Augusto Veronezi Salvador 
Sent: Tuesday, March 1, 2022 5:08:55 PM
To: dev@cloudstack.apache.org 
Subject: Re: [VOTE] CentOS 7 KVM binaries

Hi, Andrija and Paul,

This is the vote thread, not the discussion one. The goal of this
thread is to account votes to verify the agreement of the community
with the proposed solution that we seem to have in the discussion
thread. For discussions, please refer to the discussion thread[¹].
The goal is to collect +1 and -1 to show the community agreement
with the proposal that we discussed.

Best regards,
Daniel Salvador


[¹] https://lists.apache.org/thread/z7s0774n72v4o9dnl140wvm030bxovjd


On 28/02/2022 20:04, Andrija Panic wrote:

What Paul said...







On Mon, 28 Feb 2022 at 22:01, Paul Angus  wrote:

A vote really isn't required for this.

No one disagrees, so just do it.



Kind Regards


Paul Angus

-Original Message-
From: Wei ZHOU 
Sent: Monday, February 28, 2022 4:19 PM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] CentOS 7 KVM binaries

+1 (binding)

Daniel, does this need to be approved by the PMC ?

-Wei

On Mon, 28 Feb 2022 at 17:08, Daniel Salvador

Hi all, this is the vote thread that emerged from the thread
"[Discussion] CentOS 7 KVM binaries"[¹].

As discussed in the thread, users already install (without any
official guide provided by the community) the qemu-kvm-ev binary
in their environments to run CloudStack + CentOS + KVM with all

features.

With that said, to solve the situation described in the
discussion thread[¹], I propose the following:

- On CloudStack's Installation Guide > Host KVM Installation[²],
we add a section guiding users to install the qemu-kvm-ev
binaries, if they are using CentOS 7.
 - The packages that we will guide users to install will be
the latest provided by the official CentOS site[³] (the current
latest version is '2.12.0-44.1.el7_8.1.x86_64').

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 reason why)

If this gets approved, I'll open a PR on CloudStack Documentation
repository[⁴].


Best regards,
Daniel Salvador


[¹]
https://lists.apache.org/thread/z7s0774n72v4o9dnl140wvm030bxovjd
[²]



http://docs.cloudstack.apache.org/en/latest/installguide/hypervisor/kv

m.html [³]


http://mirror.centos.org/centos-7/7/virt/x86_64/kvm-common/Packages/q/

[⁴] https://github.com/apache/cloudstack-documentation

Re: [VOTE] CentOS 7 KVM binaries

[Daniel Augusto Veronezi Salvador]

Rohit,

As we are deciding a requirement for deploying ACS + KVM + CentOS 7, I 
see it as an important technical decision, that is why I started the 
voting thread. The discussion was made via another thread[¹]; therefore, 
this vote was created with the intention to summarize the discussion we 
had and then to officially approve (or not approve) the idea discussed.


Finally, to emphasize, this is the voting thread, intended to reflect 
the decision we seem to have agreed upon in the other thread[¹]. I would 
kindly ask to avoid polluting this thread with discussions not related 
to the voting itself. Furthermore, as already stated, there is a 
consensus in the discussion thread; therefore, there is no harm in 
giving a +1 here.


Best regards,
Daniel Salvador

[¹] https://lists.apache.org/thread/z7s0774n72v4o9dnl140wvm030bxovjd

On 01/03/2022 16:56, Rohit Yadav wrote:

(phone issue sent draft accidentally)... where consensus is built without 
opposition. Therefore this vote thread isn't necessary.

Refer to project bylaws https://cloudstack.apache.org/bylaws.html

Regards.

From: Daniel Augusto Veronezi Salvador 
Sent: Tuesday, March 1, 2022 5:08:55 PM
To: dev@cloudstack.apache.org 
Subject: Re: [VOTE] CentOS 7 KVM binaries

Hi, Andrija and Paul,

This is the vote thread, not the discussion one. The goal of this thread
is to account votes to verify the agreement of the community with the
proposed solution that we seem to have in the discussion thread. For
discussions, please refer to the discussion thread[¹].
The goal is to collect +1 and -1 to show the community agreement with
the proposal that we discussed.

Best regards,
Daniel Salvador


[¹] https://lists.apache.org/thread/z7s0774n72v4o9dnl140wvm030bxovjd


On 28/02/2022 20:04, Andrija Panic wrote:

What Paul said...

  


On Mon, 28 Feb 2022 at 22:01, Paul Angus  wrote:


A vote really isn't required for this.

No one disagrees, so just do it.



Kind Regards


Paul Angus

-Original Message-
From: Wei ZHOU 
Sent: Monday, February 28, 2022 4:19 PM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] CentOS 7 KVM binaries

+1 (binding)

Daniel, does this need to be approved by the PMC ?

-Wei

On Mon, 28 Feb 2022 at 17:08, Daniel Salvador 
wrote:


Hi all, this is the vote thread that emerged from the thread
"[Discussion] CentOS 7 KVM binaries"[¹].

As discussed in the thread, users already install (without any
official guide provided by the community) the qemu-kvm-ev binary in
their environments to run CloudStack + CentOS + KVM with all features.

With that said, to solve the situation described in the discussion
thread[¹], I propose the following:

- On CloudStack's Installation Guide > Host KVM Installation[²], we
add a section guiding users to install the qemu-kvm-ev binaries, if
they are using CentOS 7.
- The packages that we will guide users to install will be the
latest provided by the official CentOS site[³] (the current latest
version is '2.12.0-44.1.el7_8.1.x86_64').

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 reason why)

If this gets approved, I'll open a PR on CloudStack Documentation
repository[⁴].


Best regards,
Daniel Salvador


[¹] https://lists.apache.org/thread/z7s0774n72v4o9dnl140wvm030bxovjd
[²]

http://docs.cloudstack.apache.org/en/latest/installguide/hypervisor/kv
m.html [³]
http://mirror.centos.org/centos-7/7/virt/x86_64/kvm-common/Packages/q/
[⁴] https://github.com/apache/cloudstack-documentation

Re: [VOTE] CentOS 7 KVM binaries

[Daniel Augusto Veronezi Salvador]

Hi, Andrija and Paul,

This is the vote thread, not the discussion one. The goal of this thread 
is to account votes to verify the agreement of the community with the 
proposed solution that we seem to have in the discussion thread. For 
discussions, please refer to the discussion thread[¹].
The goal is to collect +1 and -1 to show the community agreement with 
the proposal that we discussed.


Best regards,
Daniel Salvador


[¹] https://lists.apache.org/thread/z7s0774n72v4o9dnl140wvm030bxovjd


On 28/02/2022 20:04, Andrija Panic wrote:

What Paul said...

On Mon, 28 Feb 2022 at 22:01, Paul Angus  wrote:


A vote really isn't required for this.

No one disagrees, so just do it.



Kind Regards


Paul Angus

-Original Message-
From: Wei ZHOU 
Sent: Monday, February 28, 2022 4:19 PM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] CentOS 7 KVM binaries

+1 (binding)

Daniel, does this need to be approved by the PMC ?

-Wei

On Mon, 28 Feb 2022 at 17:08, Daniel Salvador 
wrote:


Hi all, this is the vote thread that emerged from the thread
"[Discussion] CentOS 7 KVM binaries"[¹].

As discussed in the thread, users already install (without any
official guide provided by the community) the qemu-kvm-ev binary in
their environments to run CloudStack + CentOS + KVM with all features.

With that said, to solve the situation described in the discussion
thread[¹], I propose the following:

- On CloudStack's Installation Guide > Host KVM Installation[²], we
add a section guiding users to install the qemu-kvm-ev binaries, if
they are using CentOS 7.
   - The packages that we will guide users to install will be the
latest provided by the official CentOS site[³] (the current latest
version is '2.12.0-44.1.el7_8.1.x86_64').

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 reason why)

If this gets approved, I'll open a PR on CloudStack Documentation
repository[⁴].


Best regards,
Daniel Salvador


[¹] https://lists.apache.org/thread/z7s0774n72v4o9dnl140wvm030bxovjd
[²]

http://docs.cloudstack.apache.org/en/latest/installguide/hypervisor/kv
m.html [³]
http://mirror.centos.org/centos-7/7/virt/x86_64/kvm-common/Packages/q/
[⁴] https://github.com/apache/cloudstack-documentation

Re: [ANNOUNCE] New committer: Slavka Peleva

[Daniel Augusto Veronezi Salvador]

Congratulations, Slavka!


Best regards,

Daniel Salvador

On 21/12/2021 09:48, Gabriel Beims Bräscher wrote:

The Project Management Committee (PMC) for Apache CloudStack
has invited Slavka Peleva to become a committer and we are pleased
to announce that she has accepted.

Slavka has shown commitment to the Apache CloudStack community,
contributing with technical discussions in mailing lists, proposing
features, reviewing & testing PRs, creating PRs, resulting in relevant
contributions merged in the upstream.

Being a committer enables easier contribution to the
project since there is no need to go via the patch
submission process. This should enable better productivity.
A PMC member helps manage and guide the direction of the project.

Let´s congratulate and welcome Slavka, Apache CloudStack’s newest committer.

Re: [ANNOUNCE] New committer: Ivet Petrova

[Daniel Augusto Veronezi Salvador]

Congratulations, Ivet!


Best regards,

Daniel Salvador


On 21/12/2021 09:48, Gabriel Beims Bräscher wrote:

The Project Management Committee (PMC) for Apache CloudStack
has invited Ivet Petrova to become a committer and we are pleased
to announce that she has accepted.

Ivet has shown commitment to the Apache CloudStack community. Ivet has been
contributing to discussions related to marketing and community development,
organizing events, social media posts, interviews, videos, etc.

Being a committer enables easier contribution to the
project since there is no need to go via the patch
submission process. This should enable better productivity.
A PMC member helps manage and guide the direction of the project.

Let´s congratulate and welcome Ivet, Apache CloudStack’s newest committer.

Re: [VOTE] Apache CloudStack 4.16.0.0 (RC3)

[Daniel Augusto Veronezi Salvador]

Hi Nicolas, thanks for the work!

I'm +1 on the RC3, regarding to my tests:

- I manual seeded KVM's systemvm-template 4.16.0, builded the packages 
without profile "noredist" and upgraded ACS from 4.15.0 to 4.16.0.0 RC3;


- I validated basic UI (configurations were kept);

- I tested some VM, volume, snapshot, template and network lifecycle.


Best regards,

Daniel Salvador


On 04/11/2021 15:41, Nicolas Vazquez wrote:

Hi All,
I have created a 4.16.0.0 release (RC3), with the following artifacts up for 
testing and a vote:

Git Branch and Commit SHA:
https://github.com/apache/cloudstack/tree/4.16.0.0-RC20211104T1414
Commit: 44c08b5acc598972b4f0af576ffdea4e2447cb41

Source release (checksums and signatures are available at the same location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.16.0.0/

PGP release keys (signed using 656E1BCC8CB54F84):
https://dist.apache.org/repos/dist/release/cloudstack/KEYS

The vote will be open until 8th November 2021.

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 reason why)

For users convenience, the packages from this release candidate (RC3) and
4.16.0 systemvmtemplates are available here:
https://download.cloudstack.org/testing/41600-RC3/
https://download.cloudstack.org/systemvm/4.16/

Regards,
Nicolas Vazquez

  

Re: [VOTE] Apache CloudStack 4.16.0.0 (RC2)

[Daniel Augusto Veronezi Salvador]

Hi Nicolas, thanks for the work!

I'm +1 on the RC2, regarding to my tests.

- I tested upgrading from ACS 4.15.0 to 4.16.0RC2:
- I builded packages without profile "noredist";
- I manual seeded KVM's systemvm-template 4.16.0;
- I validated basic UI (configurations were kept);
- I tested some features:
   - VM (start, edit, stop, migration and live scale);
   - Volume (migration);
   - Snapshot (take and revert);
   - Template (register);
   - Network (VPC and static NAT);


Best Regards,
Daniel Salvador

On 25/10/2021 10:55, Nicolas Vazquez wrote:

Hi All,

I have created a 4.16.0.0 release (RC2), with the following artifacts up for 
testing and a vote:

Git Branch and Commit SHA:
https://github.com/apache/cloudstack/tree/4.16.0.0-RC20211025T0851
Commit: 1e070be4c9a87650f48707a44efff2796dfa802a

Source release (checksums and signatures are available at the same location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.16.0.0/

PGP release keys (signed using 656E1BCC8CB54F84):
https://dist.apache.org/repos/dist/release/cloudstack/KEYS

The vote will be open until 28th October 2021, 16.00 CET (72h).

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 reason why)

For users convenience, the packages from this release candidate (RC2) and
4.16.0 systemvmtemplates are available here:
https://download.cloudstack.org/testing/41600-RC2/
https://download.cloudstack.org/systemvm/4.16/

Regards,
Nicolas Vazquez


  

Re: [VOTE] Apache Cloudstack 4.16.0.0 RC1

[Daniel Augusto Veronezi Salvador]

Paul, I see,

I am not familiar with the details of VMware SDK JARs. However, to avoid 
mixing things up I suggest we create an issue to discuss this topic in 
the future.


What I pointed out is that the process of downloading system VMs 
templates was added in the "noredist" profile, which is, right now, used 
to build ACS with VMware JARs (not judging if we need or not to handle 
this process in an isolated profile). I then suggested to separate that 
process into specific build profiles, so we can activate/deactivate the 
download process whenever we want, and also to avoid mix this process 
(download of system VMs templates) with VMware JAR packaging.


Best regards,
Daniel Salvador


On 20/10/2021 15:37, Paul Angus wrote:

Thanks Daniel,

My point is that I'm not sure that the VMware jars _need_ to be noredist, which 
would simplify things for everyone.

Kind Regards


Paul Angus

-Original Message-----
From: Daniel Augusto Veronezi Salvador 
Sent: Wednesday, October 20, 2021 6:20 PM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] Apache Cloudstack 4.16.0.0 RC1

Paul,


Noredist packages are only necessary to VMWare.

KVM/XenServer infrastructures don't use noredist packages.


Best regards,
Daniel Salvador

On 20/10/2021 12:29, Paul Angus wrote:

I vaguely thought that the VMware jars come under a compatible license these 
days, so don't need to be noredist anymore?


-Original Message-----
From: Daniel Augusto Veronezi Salvador 
Sent: Wednesday, October 20, 2021 2:53 PM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] Apache Cloudstack 4.16.0.0 RC1

Hi Nicolas, thanks for the work.

I started testing this RC and unfortunately I ran into some problems related to 
building/upgrading ACS.

   From the less to the more complex:

- When building ".deb", there is a problem with the Debian changelog:
invalid weekday 'lun';

- Regarding auto upgrading "systemvms-templates", I analyzed the code and concluded that 
"systemvms-templates" will only "autoupgrade" if we use the profile "noredist" when 
building the packages, which is necessary only to VMWare. Some people, might not want the noredist JARs, and therefore 
will not build with this profile. With that said, there are some points regarding it that I think are important:
  - Package "cloudstack-management" goes from ~100Mb to more than 1.5Gb, when using "noredist" 
while executing the 4.16.0.0 build. It happens due to "cloudstack/engine/schema/pom.xml" automatically 
downloading XenServer, KVM, and VMware "systemvms-templates". Every time that we build the packages, it will 
download all these systemvms-templates; we are unable to decide which one is necessary or not. If we do not use 
XenServer, or other hypervisors, why download it?
  - If we build the packages with "noredist", when we are first running ACS 
after upgrading it to 4.16, it will try to autoupgrade the systemvms-templates, however, 
some KVM/XenServer infrastructures don't allow the management server to access the 
secondary storage directly (except for the first systemvm-template seed). This will cause
"mount.nfs: access denied by server while mounting ".
After generating this error, ACS continues the upgrade and updates the 
database; however, the new systemvm-template will not be in the secondary 
storage. If we try to deploy a system (like virtual router), it will fail (as 
expected).
  - I rolled back my environment to 4.15, did a manual seed of 
systemvmtemplate-4.16.0-kvm.qcow2.bz2, built the packages without "noredist" 
and tried to upgrade the environment to 4.16. Then, ACS automatically tried to upgrade 
the systemvm-templates; even though the system VM template for 4.16 is already there, it 
throws some errors:

2021-10-19 23:08:02,684 DEBUG [c.c.u.d.Upgrade41520to41600] (main:null)
(logid:) Updating System Vm template IDs
2021-10-19 23:08:02,904 DEBUG [c.c.u.SystemVmTemplateRegistration]
(main:null) (logid:) Updating System Vm template IDs
2021-10-19 23:08:02,910 DEBUG [c.c.u.SystemVmTemplateRegistration]
(main:null) (logid:) Updating VMware System Vms
2021-10-19 23:08:02,915 WARN  [c.c.u.SystemVmTemplateRegistration]
(main:null) (logid:) 4.16.0 VMware SystemVm template not found. Cannot upgrade 
system Vms hypervisor is not used, so not failing upgrade
2021-10-19 23:08:02,962 DEBUG [c.c.u.SystemVmTemplateRegistration]
(main:null) (logid:) Updating KVM System Vms
2021-10-19 23:08:02,966 INFO  [c.c.u.SystemVmTemplateRegistration]
(main:null) (logid:) Grabbing lock to register templates.
2021-10-19 23:08:02,976 ERROR [c.c.u.SystemVmTemplateRegistration]
(main:null) (logid:) Failed to calculate template checksum
java.nio.file.NoSuchFileException:
/usr/share/cloudstack-management/templates/systemvm/systemvmtemplate-4.16.0-kvm.qcow2.bz2
   at
java.base/sun.nio.fs.UnixExcep

Re: [VOTE] Apache Cloudstack 4.16.0.0 RC1

[Daniel Augusto Veronezi Salvador]

Paul,


Noredist packages are only necessary to VMWare.

KVM/XenServer infrastructures don't use noredist packages.


Best regards,
Daniel Salvador

On 20/10/2021 12:29, Paul Angus wrote:

I vaguely thought that the VMware jars come under a compatible license these 
days, so don't need to be noredist anymore?


-Original Message-----
From: Daniel Augusto Veronezi Salvador 
Sent: Wednesday, October 20, 2021 2:53 PM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] Apache Cloudstack 4.16.0.0 RC1

Hi Nicolas, thanks for the work.

I started testing this RC and unfortunately I ran into some problems related to 
building/upgrading ACS.

  From the less to the more complex:

- When building ".deb", there is a problem with the Debian changelog:
invalid weekday 'lun';

- Regarding auto upgrading "systemvms-templates", I analyzed the code and concluded that 
"systemvms-templates" will only "autoupgrade" if we use the profile "noredist" when 
building the packages, which is necessary only to VMWare. Some people, might not want the noredist JARs, and therefore 
will not build with this profile. With that said, there are some points regarding it that I think are important:
     - Package "cloudstack-management" goes from ~100Mb to more than 1.5Gb, when using "noredist" 
while executing the 4.16.0.0 build. It happens due to "cloudstack/engine/schema/pom.xml" automatically 
downloading XenServer, KVM, and VMware "systemvms-templates". Every time that we build the packages, it will 
download all these systemvms-templates; we are unable to decide which one is necessary or not. If we do not use 
XenServer, or other hypervisors, why download it?
     - If we build the packages with "noredist", when we are first running ACS 
after upgrading it to 4.16, it will try to autoupgrade the systemvms-templates, however, 
some KVM/XenServer infrastructures don't allow the management server to access the 
secondary storage directly (except for the first systemvm-template seed). This will cause
"mount.nfs: access denied by server while mounting ".
After generating this error, ACS continues the upgrade and updates the 
database; however, the new systemvm-template will not be in the secondary 
storage. If we try to deploy a system (like virtual router), it will fail (as 
expected).
     - I rolled back my environment to 4.15, did a manual seed of 
systemvmtemplate-4.16.0-kvm.qcow2.bz2, built the packages without "noredist" 
and tried to upgrade the environment to 4.16. Then, ACS automatically tried to upgrade 
the systemvm-templates; even though the system VM template for 4.16 is already there, it 
throws some errors:

2021-10-19 23:08:02,684 DEBUG [c.c.u.d.Upgrade41520to41600] (main:null)
(logid:) Updating System Vm template IDs
2021-10-19 23:08:02,904 DEBUG [c.c.u.SystemVmTemplateRegistration]
(main:null) (logid:) Updating System Vm template IDs
2021-10-19 23:08:02,910 DEBUG [c.c.u.SystemVmTemplateRegistration]
(main:null) (logid:) Updating VMware System Vms
2021-10-19 23:08:02,915 WARN  [c.c.u.SystemVmTemplateRegistration]
(main:null) (logid:) 4.16.0 VMware SystemVm template not found. Cannot upgrade 
system Vms hypervisor is not used, so not failing upgrade
2021-10-19 23:08:02,962 DEBUG [c.c.u.SystemVmTemplateRegistration]
(main:null) (logid:) Updating KVM System Vms
2021-10-19 23:08:02,966 INFO  [c.c.u.SystemVmTemplateRegistration]
(main:null) (logid:) Grabbing lock to register templates.
2021-10-19 23:08:02,976 ERROR [c.c.u.SystemVmTemplateRegistration]
(main:null) (logid:) Failed to calculate template checksum
java.nio.file.NoSuchFileException:
/usr/share/cloudstack-management/templates/systemvm/systemvmtemplate-4.16.0-kvm.qcow2.bz2
      at
java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
      at
java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
      at
java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
      at
java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:219)
      at java.base/java.nio.file.Files.newByteChannel(Files.java:371)
      at java.base/java.nio.file.Files.newByteChannel(Files.java:422)
      at
java.base/java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:420)
      at java.base/java.nio.file.Files.newInputStream(Files.java:156)
      at
com.cloud.upgrade.SystemVmTemplateRegistration.calculateChecksum(SystemVmTemplateRegistration.java:330)
      at
com.cloud.upgrade.SystemVmTemplateRegistration.validateTemplates(SystemVmTemplateRegistration.java:690)
      at
com.cloud.upgrade.SystemVmTemplateRegistration.registerTemplates(SystemVmTemplateRegistration.java:713)
      at
com.cloud.upgrade.SystemVmTemplateRegistration$5.doInTransactionWithoutResult(SystemVmTemplateRegistration.java:824)
      at
com.cloud.ut

Re: [VOTE] Apache Cloudstack 4.16.0.0 RC1

[Daniel Augusto Veronezi Salvador]

Hi Nicolas, thanks for the work.

I started testing this RC and unfortunately I ran into some problems 
related to building/upgrading ACS.


From the less to the more complex:

- When building ".deb", there is a problem with the Debian changelog: 
invalid weekday 'lun';


- Regarding auto upgrading "systemvms-templates", I analyzed the code 
and concluded that "systemvms-templates" will only "autoupgrade" if we 
use the profile "noredist" when building the packages, which is 
necessary only to VMWare. Some people, might not want the noredist JARs, 
and therefore will not build with this profile. With that said, there 
are some points regarding it that I think are important:
   - Package "cloudstack-management" goes from ~100Mb to more than 
1.5Gb, when using "noredist" while executing the 4.16.0.0 build. It 
happens due to "cloudstack/engine/schema/pom.xml" automatically 
downloading XenServer, KVM, and VMware "systemvms-templates". Every time 
that we build the packages, it will download all these 
systemvms-templates; we are unable to decide which one is necessary or 
not. If we do not use XenServer, or other hypervisors, why download it?
   - If we build the packages with "noredist", when we are first 
running ACS after upgrading it to 4.16, it will try to autoupgrade the 
systemvms-templates, however, some KVM/XenServer infrastructures don't 
allow the management server to access the secondary storage directly 
(except for the first systemvm-template seed). This will cause 
"mount.nfs: access denied by server while mounting ". 
After generating this error, ACS continues the upgrade and updates the 
database; however, the new systemvm-template will not be in the 
secondary storage. If we try to deploy a system (like virtual router), 
it will fail (as expected).
   - I rolled back my environment to 4.15, did a manual seed of 
systemvmtemplate-4.16.0-kvm.qcow2.bz2, built the packages without 
"noredist" and tried to upgrade the environment to 4.16. Then, ACS 
automatically tried to upgrade the systemvm-templates; even though the 
system VM template for 4.16 is already there, it throws some errors:


2021-10-19 23:08:02,684 DEBUG [c.c.u.d.Upgrade41520to41600] (main:null) 
(logid:) Updating System Vm template IDs
2021-10-19 23:08:02,904 DEBUG [c.c.u.SystemVmTemplateRegistration] 
(main:null) (logid:) Updating System Vm template IDs
2021-10-19 23:08:02,910 DEBUG [c.c.u.SystemVmTemplateRegistration] 
(main:null) (logid:) Updating VMware System Vms
2021-10-19 23:08:02,915 WARN  [c.c.u.SystemVmTemplateRegistration] 
(main:null) (logid:) 4.16.0 VMware SystemVm template not found. Cannot 
upgrade system Vms hypervisor is not used, so not failing upgrade
2021-10-19 23:08:02,962 DEBUG [c.c.u.SystemVmTemplateRegistration] 
(main:null) (logid:) Updating KVM System Vms
2021-10-19 23:08:02,966 INFO  [c.c.u.SystemVmTemplateRegistration] 
(main:null) (logid:) Grabbing lock to register templates.
2021-10-19 23:08:02,976 ERROR [c.c.u.SystemVmTemplateRegistration] 
(main:null) (logid:) Failed to calculate template checksum
java.nio.file.NoSuchFileException: 
/usr/share/cloudstack-management/templates/systemvm/systemvmtemplate-4.16.0-kvm.qcow2.bz2
    at 
java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
    at 
java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
    at 
java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
    at 
java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:219)

    at java.base/java.nio.file.Files.newByteChannel(Files.java:371)
    at java.base/java.nio.file.Files.newByteChannel(Files.java:422)
    at 
java.base/java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:420)

    at java.base/java.nio.file.Files.newInputStream(Files.java:156)
    at 
com.cloud.upgrade.SystemVmTemplateRegistration.calculateChecksum(SystemVmTemplateRegistration.java:330)
    at 
com.cloud.upgrade.SystemVmTemplateRegistration.validateTemplates(SystemVmTemplateRegistration.java:690)
    at 
com.cloud.upgrade.SystemVmTemplateRegistration.registerTemplates(SystemVmTemplateRegistration.java:713)
    at 
com.cloud.upgrade.SystemVmTemplateRegistration$5.doInTransactionWithoutResult(SystemVmTemplateRegistration.java:824)
    at 
com.cloud.utils.db.TransactionCallbackNoReturn.doInTransaction(TransactionCallbackNoReturn.java:25)
    at 
com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:50)

    at com.cloud.utils.db.Transaction.execute(Transaction.java:40)
    at com.cloud.utils.db.Transaction.execute(Transaction.java:47)
    at 
com.cloud.upgrade.SystemVmTemplateRegistration.updateSystemVmTemplates(SystemVmTemplateRegistration.java:802)
    at 
com.cloud.upgrade.dao.Upgrade41520to41600.updateSystemVmTemplates(Upgrade41520to41600.java:105)
    at 
com.cloud.upgrade.DatabaseUpgradeChecker.updateSystemVmTemplates(DatabaseUpgradeChecker.java:258)
    at 
com.cloud.upgrade.Datab

Re: [DISCUSS] Way to fix a problem with KVM snapshots for non-managed storages

[Daniel Augusto Veronezi Salvador]

Hi Slavka,

In my POV, volume/VM deletion behavior when "snapshot.backup.to.secondary" is 
"false" should be the same as when it's "true", regarding to disk snapshots. 
What changes to snapshots is the location of they, therefore, operators should 
be able to do any operation with them on primary, as when they are on 
secondary. 

With that said, I see two ways to achieve this:

1. Backup the snapshot to secondary;
2. As operators choose to not backup snapshots at first, their features should 
be adapted to work with primary storage;

Best regards,
Daniel.

On 2021/09/14 07:20:12, Slavka Peleva  wrote: 
> Hi all,
> 
> There is a problem with snapshots kept only on primary storage for
> non-managed drivers, and I've opened an issue request #5433
> 
> The problem is when we delete a volume with more than one snapshot kept
> only on primary with the option snapshot.backup.to.secondary to false. And
> the behaviour is different for most of the non-managed drivers.
> My question is which is the best way to handle this?
> For me the better option is each driver to handle this (if there is need to
> delete the snapshots from DB/storage or they could live without the volume)
> 
> Thanks for the help!
> 
> 
> Best regards,
> Slavka
> 

[RESULT] [VOTE] Standard string lib

[Daniel Augusto Veronezi Salvador]

Hi All,

The vote for Standard string lib 
(https://lists.apache.org/thread.html/r806cd10b3de645c150e5e0e3d845c5a380a700197143f57f0834d758%40%3Cdev.cloudstack.apache.org%3E)
 *passes* with 8 votes:

+1
6 people (Daan, Gabriel, Nicolas, Pearl, Rodrigo and Sadi)

0
2 people (Rohit and Wido)

-1
none

Thanks to everyone participating. I will now continue the work in PR 5386 
(https://github.com/apache/cloudstack/pull/5386), adjusting the description and 
addressing what we decided here. After that, I will update the docs.

Best regards,
Daniel.

Re: [VOTE] Standard string lib

[Daniel Augusto Veronezi Salvador]

Rohit, sure.

About the points:

1. The objective of the vote is to see if all are in favor of using 
"commons.lang3" as the String standard library and for String operations 
not covered on "commons.lang3", we use our StringUtils (as we discussed 
in the discussion thread - 
https://lists.apache.org/thread.html/r806cd10b3de645c150e5e0e3d845c5a380a700197143f57f0834d758%40%3Cdev.cloudstack.apache.org%3E). 
Then, if the vote passes, I will create the PR to address this change in 
the code base by removing unnecessary libraries, and changing the code 
to use "commons.lang3"'. Te proposal is to use "lang3" as the standard 
String library; therefore, I will replace every occurrence of others 
String libraries by "lang3" (and update "lang" to "lang3"). Our (facade) 
StringUtils will be only to specific methods that "lang3" doesn't cover, 
like "csvTagsToList", "areTagsEqual" and others.


2. As there are many libraries, what I could do is to add the module 
"IllegalImport" to the checkstyle and verify the libraries I will remove 
in the refactor.


3. I will update the code conventions wiki/docs with the outcome of this 
vote, and then we will be able to use it as a guideline in our reviews.


Best regards,
Daniel

On 14/09/2021 05:35, Rohit Yadav wrote:

Daniel - can you explain what are we exactly voting for?

I get that your vote thread is primarily about moving to commons-lang3 but it 
does not explain the plan and logistics, for example what about:

   *   Creating a utility facade under cloud-api and using that throughout the 
codebase; or is it find-replace all usage of google's Strings with common-lang3?
   *   Introducing specific checks via checkstyle plugin to enforce developers 
(https://github.com/apache/cloudstack/tree/main/tools/checkstyle)
   *   Updating the code conventions wiki/docs

Regards.


From: Pearl d'Silva 
Sent: Tuesday, September 14, 2021 09:27
To: dev@cloudstack.apache.org 
Subject: Re: [VOTE] Standard string lib

+1. Sounds like a good plan.

From: Gabriel Br?scher 
Sent: Monday, September 13, 2021 9:15 PM
To: dev 
Subject: Re: [VOTE] Standard string lib

+1

On Mon, Sep 13, 2021, 12:40 Sadi  wrote:


+1

Good idea.

On 13/09/2021 12:02, Daniel Augusto Veronezi Salvador wrote:

Hi All,

We had a discussion about standardizing the string libs we're using (

https://lists.apache.org/thread.html/r806cd10b3de645c150e5e0e3d845c5a380a700197143f57f0834d758%40%3Cdev.cloudstack.apache.org%3E
).

As I proposed, I'm opening this voting thread to see if all are in favor

of using "commons.lang3" as the String standard library and for String
operations not convered on "commons.lang3", we use our StringUtils. Then,
if the vote passes, I will create the PR to address this change in the code
base by removing unnecessary libraries, and changing the code to use
"commons.lang3".

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Best regards,
Daniel





  

[VOTE] Standard string lib

[Daniel Augusto Veronezi Salvador]

Hi All,

We had a discussion about standardizing the string libs we're using 
(https://lists.apache.org/thread.html/r806cd10b3de645c150e5e0e3d845c5a380a700197143f57f0834d758%40%3Cdev.cloudstack.apache.org%3E).

As I proposed, I'm opening this voting thread to see if all are in favor of 
using "commons.lang3" as the String standard library and for String operations 
not convered on "commons.lang3", we use our StringUtils. Then, if the vote 
passes, I will create the PR to address this change in the code base by 
removing unnecessary libraries, and changing the code to use "commons.lang3".

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Best regards,
Daniel

Re: [Discussion] String libs

[Daniel Augusto Veronezi Salvador]

tember 8, 2021 5:05 AM
 > > To: dev@cloudstack.apache.org 
 > > Subject: Re: [Discussion] String libs
 > >
 > > I don't have any specific inclination, I would use whatever
becomes a
 > > standard.
 > >
 > > However, I prefer the readability of a utility method that is
readable
 > and
 > > easy to understand such as isNullOrEmpty (which suggests it's
doing a
 > null
 > > check) versus isEmpty.
 > >
 > > I suppose a refactoring exercise can be done by picking whatever
 > favourite
 > > dependency community consensus is built for (if at all) and then
write a
 > > utility method in something like StringsUtil in cloud-utils and
use it
 > > throughout the codebase so in future if we want to move to
something
 > else -
 > > all you do is replace your favourite dependency with something new
only
 > in
 > > StringsUtils of cloud-utils.
 > >
 > > ... and update the cloudstack-checkstyle to enforce the new agreed
upon
 > > rule and also update -
 > >
 >
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Coding+conventions
 > >
 > >
 > > Regards.
 > >
 > > 
 > > From: Daniel Augusto Veronezi Salvador 
 > > Sent: Tuesday, September 7, 2021 04:37
 > > To: dev@cloudstack.apache.org 
 > > Subject: [Discussion] String libs
 > >
 > > Hi all,
 > >
 > > Currently, the main String libs we are using are "commons.lang" and
 > > "commons.lang3" (either directly or by our facade,
"com.cloud.utils"). We
 > > have a current discussion about using them directly or via a
facade (such
 > > as "com.cloud.utils"); however, a third implementation has been
added
 > > (google.common.base), which adds more to the discussion.
"commons.lang"
 > > already implement all we need; therefore, adding a third one does
not
 > seem
 > > to add/improve/help with anything, but adding more moving parts and
 > > libraries that we need to watch out for (managing versions,
checking for
 > > security issues, and so on).
 > >
 > > I created a PR (https://github.com/apache/cloudstack/pull/5386) to
 > > replace "google.common.base" with "commons.lang3". However, and as
Daan
 > > suggested too, I'd like to go forward and revisit this discussion
to
 > > standardize our code. To guide it, I'd like to start with what I
think is
 > > the main topic:
 > >
 > > - Should we use a facade to "commons.lang"? Which are the pros and
cons,
 > > according to your perspective?
 > >
 > > Best regards,
 > > Daniel.
 > >
 > >
 > >
 > >
 > >
 > >
 > >
 >
 > --
 > Daan
 >

Re: [Discussion] Release Cycle

[Daniel Augusto Veronezi Salvador]

Hi Gabriel, thanks for opening this discussion.

I'm +1 on it. My considerations:

- We've to put a lot of efforts to support 3+ LTS simultaneously, which 
doesn't make sense. Regular versions will give us some breath and will 
reduce rework.
- Although the EOL is well defined, it seems we don't have a solid 
criteria to define new versions, because they don't have a pattern. 
Users don't know when they will have a new version. Also, we don't have 
much planning to do the implementations.
- We've been seeing Ubuntu life-cycle working for a long time, and we 
know it works well. It's a good reference to follow, we will not need to 
reinvent the wheel.


Best regards,
Daniel.

On 31/08/2021 14:44, Gabriel Bräscher wrote:

Hello,

I would like to open a discussion regarding the project release cycle. More
specifically on the following topics:

1. LTS and Regular releases

2. Releases period

3. Enhance roadmap and Release cycle for users

 1 LTS and Regular releases

It has been a while since the last regular release. Nowadays there are only
LTS releases; maybe we should get back to having regular versions in
between LTS.

With a “Regular” release users would be able to trade stability for new
features. Additionally, developers and users would have a “pilot” of the
next LTS which could anticipate issues and result in a stable long-term
release.

Please, let me know what you think of this. Should we get back to releasing
Regular releases in between LTS releases?

For reference, here follow the past releases:

+-+-+--+-+
| Release | Type| Release date | EOL |
+-+-+--+-+
| 4.15| LTS | 19 Jan 2021  | 1 July 2022 |
+-+-+--+-+
| 4.14| LTS | 26 May 2020  | 1 Jan 2022  |
+-+-+--+-+
| 4.13| LTS | 24 Sep. 2019 | 1 May 2021  |
+-+-+--+-+
| 4.12| Regular | 4 April 2019 | N/A |
+-+-+--+-+
| 4.11| LTS | 12 Feb. 2018 | 1 July 2019 |
+-+-+--+-+
| 4.10| Regular | 6 July 2017  | N/A |
+-+-+--+-+
| 4.9 | LTS | 25 July 2016 | 1 July 2018 |
+-+-+--+-+

 2 Releases period


We had in the past a new LTS per year. Then, we got into two new LTS per
year. This led from having 2 LTS maintained at the same time to 3.
With that said, I think this is neither documented nor has it been
discussed in the ML.

We have the LTS minimum and maximum support dates well defined, but so far
there is no definition/guidelines towards the release period.
I would like to open this discussion so we can update the CloudStack wiki
page [https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS] and have
a clear definition of when the community should expect each release.

 3 Enhance roadmap and Release cycle for users

This topic is an extension of Topic 2. Once we have “Topic 2” well defined
we will be able to present a draft of future releases.

The main idea of this email is to look for project stability and
predictability with a release cycle/roadmap similar to what is done by
Ubuntu [https://ubuntu.com/about/release-cycle].
We would then be able to give users and developers a roadmap to look after.
I would also suggest such a release cycle to be presented on the website,
in addition to the “cwiki” page [
https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS].

Please let me know what you think.

Best regards,
Gabriel.

[Discussion] String libs

[Daniel Augusto Veronezi Salvador]

Hi all,

Currently, the main String libs we are using are "commons.lang" and 
"commons.lang3" (either directly or by our facade, "com.cloud.utils"). We have 
a current discussion about using them directly or via a facade (such as 
"com.cloud.utils"); however, a third implementation has been added 
(google.common.base), which adds more to the discussion. "commons.lang" already 
implement all we need; therefore, adding a third one does not seem to 
add/improve/help with anything, but adding more moving parts and libraries that 
we need to watch out for (managing versions, checking for security issues, and 
so on).

I created a PR (https://github.com/apache/cloudstack/pull/5386) to replace 
"google.common.base" with "commons.lang3". However, and as Daan suggested too, 
I'd like to go forward and revisit this discussion to standardize our code. To 
guide it, I'd like to start with what I think is the main topic:

- Should we use a facade to "commons.lang"? Which are the pros and cons, 
according to your perspective?

Best regards,
Daniel.

Re: [DISCUSS] 4.15.2.0

[Daniel Augusto Veronezi Salvador]

+1

- Daniel

On 19/08/2021 07:54, Rohit Yadav wrote:

All,

I want to kick a thread to discuss and gather interest from the community on 
doing a 4.15.2.0 release, before Nicolas (our RM) cuts 4.16.0.0 RC1 around the 
end of Sept '21.

We can keep the scope really tight to include only important fixes, I see about 
50 closed issues/PRs already on the 4.15.2.0 milestone and some 30 remaining:
https://github.com/apache/cloudstack/milestone/20

I'm hoping the 4.15.2.0 release can be a quick stable minor release, I can do 
it and any other volunteer RM may do it. Whoever does it, here's my proposal is:

   *   Limit the scope to very specific do-able bug-fixes up to end the month - 
so gives us roughly 2 weeks
   *   Cut RC1 in the first week of Sept
   *   Assuming the RC1 would be stable enough as 4.15 branch is quite stable, 
worst case we've another RC2
   *   Conclude release work by mid or end of Sept before 4.16.0.0 RC1 is cut; 
so 4.15.2.0 release work doesn't cause delay for 4.16.0.0

Thoughts?


Thanks and regards.