Re: Unable to download DevCloud image file

[Rohit Yadav]

Hi Lohit,

DevCloud isn't maintained or used anymore, the apache folder was removed long 
back.

You can try mbx https://github.com/shapeblue/mbx or Simulator based development 
(https://github.com/shapeblue/hackerbook/blob/main/2-dev.md#simulator-based-development)
 instead.



Regards.

 



From: Lohit S 
Sent: Wednesday, May 22, 2024 11:23
To: dev@cloudstack.apache.org 
Subject: Unable to download DevCloud image file

Hi I had tried to download the DevCloud image file from this URL  
https://people.apache.org/~bhaisaab/cloudstack/devcloud/devcloud2.ova

[image.png]
But it shows 404 error.

Re: [REVIVE][DISCUSS] Closing issues & PR after a certain time

[Rohit Yadav]

I like the general idea but at the same time want to weight in that we also do 
the right thing in handle issues and PRs. Sometimes there are genuine issues 
and PRs, however, we make no progress on them for one reason or another.

As of last week, I've triaged all the outstanding Github issues that took some 
effort, and have tagged issues with the 1yr+ and 2yr+ tags and stale tags on 
all issues that are several years old now. I hope to not have incited negative 
reactions where I had to close about 50 odd issues which were really old, or 
already fixed, or moved a few of them to discussions. I see the value in having 
an automation to something around time based manner, esp for old issues and PRs 
that nobody cares about. Other opensource projects such as Kubernetes has 
similar automation.

Many issues are (a) user queries or questions about their deployment or 
environment, and not necessarily issues or problems in CloudStack which can be 
moved to Github discussions (which are connected to our users@ ML) and (b) many 
issues are user feature requests or suggestions which nobody has cared to 
address. For (a) I've proposed a PR to drive users by default to Github 
Discussions first via the CloudStack UI and we can triage and move such user 
discussions which are not really CloudStack issues from Github issues to 
discussions.

I think 2yrs+ is a reasonable time to close old/stale/inactive issues and PRs. 
And of course, anybody should be free to re-open or request to re-open and 
retain interesting issues and PRs on case by case basis.

It's also worth encouraging and reminding everyone that CloudStack is an 
opensource project where all stakeholders including the users can pitch in, 
help with engaging in the discussions, sharing steps to reproduce a problem, or 
effort/steps to help test a change/pull-request, to improve the website and 
documentation, as well as to review/test pull requests. This means, as much as 
the development activity we get, we can also benefit from users in helping to 
address their own problems (if not including code but also) including 
documentation, website etc. "What's in it for you?" - you care, because you 
benefit from the project and you want to keep benefiting from the project.


Regards.

 



From: Daan Hoogland 
Sent: Tuesday, April 30, 2024 18:05
To: dev ; users 
Subject: [REVIVE][DISCUSS] Closing issues & PR after a certain time

People,
I want to revive this discussion and bring Vishesh' PR under your
attention again.
The discussion there is mostly about the length of the period before closing.
So here I am going to state 1year - first warning, 1.5years second
warning, 2 years closing. What do you all think?

There are also issues that we might consider interesting but not
functionally complete or clear, we can convert those to github
discussions, and I would like to encourage all of you to do that as
sometimes issues will lead to issues and not to PRs and those are
basically discussions to be had.

please respond with your comments or put them in
https://github.com/apache/cloudstack/pull/8667

regards,

On 2024/02/16 09:17:02 Vishesh Jindal wrote:
> I have created a PR with the changes 
> here:https://github.com/apache/cloudstack/pull/8667
>
> I propose that we enable it. As Daan suggested, we can always remove the 
> action if it doesn't work out. And if a PR/issue gets closed, we can always 
> reopen it.
>
>
>
> 
> From: Daan Hoogland 
> Sent: Wednesday, February 14, 2024 2:17 PM
> To: dev@cloudstack.apache.org 
> Subject: Re: [DISCUSS] Closing issues & PR after a certain time
>
> i'm a bit -0 on this. I agree that a lot of stale issues deserve
> closing, but others are really long term goals. I do not want to block
> this great idea but am just a bit worried about other great ideas
> getting lost. So I would propose to tag anything we close or not
> remove the stale tag, so these can be easily found. I am not worried
> too much about PRs, just issues.
>
> On the other hand, we can always remove the gha again, so maybe we
> should install it and see if it works for us.
>
> On Wed, Feb 14, 2024 at 4:49 AM Kiran Chavala
>  wrote:
> >
> > Good idea Vishesh
> >
> > +1 for using Githubactions
> >
> > Regards
> > Kiran
> >
> > From: Vishesh Jindal 
> > Date: Tuesday, 13 February 2024 at 6:33 PM
> > To: dev@cloudstack.apache.org 
> > Subject: [DISCUSS] Closing issues & PR after a certain time
> > Hi everyone,
> >
> > I was going through the issues and PRs, and I noticed that a lot of them 
> > are really old and some of them are waiting for the original author to 
> > reply.
> >
> > I wanted to discuss if we should add a github action 
> > (https://github.com/marketplace/actions/close-stale-issues) for auto 
> > closing the issues and PRs after a certain time.
> >
> > From the github actions' documentation, this is how it works:
> >
> >   *   Add a label "Stale" on issues and pull requests after 60 

Re: [RESULT][VOTE] Apache CloudStack 4.18.2.0

[Rohit Yadav]

Thanks João and congratulations everyone.

The deb and rpm packages are sync'd to the repos:

http://download.cloudstack.org/el/7/4.18/
http://download.cloudstack.org/el/8/4.18/
http://download.cloudstack.org/el/9/4.18/
http://download.cloudstack.org/suse/15/4.18/
http://download.cloudstack.org/ubuntu/ (bionic, focal and jammy)
and,
http://packages.shapeblue.com/cloudstack/upstream/


Regards.


From: João Jandre 
Sent: Wednesday, April 17, 2024 19:18
To: dev@cloudstack.apache.org 
Subject: [RESULT][VOTE] Apache CloudStack 4.18.2.0

Hi all,

After 120 hours, the vote for CloudStack 4.18.2.0 *passes* with
3 PMC + 2 non-PMC votes.

+1 (PMC / binding)
Daan Hoogland
Nux (Lucian)
Rohit Yadav

+1 (non binding)
Bryan Lima
Jithin Raju

0
none

-1
none

Thanks to everyone participating.

I will now prepare the release announcement to go out after 24 hours to
give the mirrors time to catch up.


 

Re: [VOTE] Apache CloudStack 4.18.2.0 RC2

[Rohit Yadav]

+1 (binding)

I've built and uploaded the 4.18.2.0 RC2 packages here for people's convenience 
- http://cloudstack.apt-get.eu/testing/4.18.2.0-rc2/

  *
Tested upgrade from 4.18.1.1 to 4.18.2.0 RC packages -ok
  *
Rebuilt systemvms (ssvm and cpvm) - ok
  *
Restart network - ok
  *
New VM deployment on existing network post-upgrade using pre-upgrade template - 
ok
  *
Login as normal and admin users - ok
  *
cmk CLI test - ok
  *
Tested on a arm64/RPi platform - ok (caveat, had to build this 
http://cloudstack.apt-get.eu/rpi4/systemvmtemplate/4.18/systemvmtemplate-4.18.1-kvm-arm64.qcow2
 and ensure before starting the mgmt server post-upgrade, had to copy the file 
to /usr/share/cloudstack-management/templates/systemvm and fix/tricky the md5 
hash in the metadata.ini)

Regards.

 



From: Jithin Raju 
Sent: Wednesday, April 17, 2024 13:54
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Subject: Re: [VOTE] Apache CloudStack 4.18.2.0 RC2

+1 tested the usual VM, network, and storage operations.


-Jithin

From: João Jandre 
Date: Friday, 12 April 2024 at 5:07 PM
To: dev@cloudstack.apache.org , 
us...@cloudstack.apache.org 
Subject: [VOTE] Apache CloudStack 4.18.2.0 RC2
Hi All,

I've created a 4.18.2.0 release (RC2), with the following artifacts up
for a vote:

Git Branch and Commit SH:
https://github.com/apache/cloudstack/tree/4.18.2.0-RC20240412T0825
Commit: 154566f914c778d448d4ab07b47b2db874bbf982

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

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

Vote will be open for 120 hours (due to the weekend).

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)

Re: [DISCUSS] New terraform git tag for registry workaround

[Rohit Yadav]

All,

Update - looks like there was a caching/delay issue, after republishing the 
provider the issue is no longer seen now (as tested with Terraform v1.8.0 CLI) 
and a workaround release may not be necessary now.

Issue reference: 
https://github.com/apache/cloudstack-terraform-provider/issues/109#issuecomment-2058519817


The only note for future release manager is to avoid publishing the artifacts 
before voting is closed, or to delete an already published release.


Regards.

 



From: Rohit Yadav 
Sent: Tuesday, April 16, 2024 13:15
To: dev 
Subject: Re: [DISCUSS] New terraform git tag for registry workaround

All,

I got the following from TF support:


Hello there, provider versions are immutable in the registry. Therefore, when 
you deleted and recreated the version in Github, the hash has changed, and the 
registry will refuse to serve it. Your option now it either to delete the 
version in the registry (which we can help you do), or publish a new version.

I tried to get the release deleted from the registry, and republished the 
releases artifacts using goreleaser but still same issue.

I think the only thing to document is that we must never delete/republish an 
artifact on the release repo: 
http://github.com/cloudstack/terraform-provider-cloudstack

We cannot use the apache one as: (1) the registry needs the repo to be named as 
terraform-provider- and (2) it would need access from asf infra to 
connect registry with the repo, and it would then need existing users to 
migrate from cloudstack/cloudstack provider namespace (as the plugin has 
history/registry even before being donated to the cloudstack project).



Regards.





From: Harikrishna Patnala 
Sent: Tuesday, April 16, 2024 11:54
To: dev 
Subject: Re: [DISCUSS] New terraform git tag for registry workaround

okay, given the situation your proposal seems right Rohit. Like Daan asked, if 
we can prevent this situation in future we need to document it also.

Regards,
Harikrishna




From: Daan Hoogland 
Sent: Monday, April 15, 2024 4:50 PM
To: dev 
Subject: Re: [DISCUSS] New terraform git tag for registry workaround

I think your proposals are ok as an ad-hoc solution to the current
situation @Rohit Yadav . I wonder how we should deal with this in the
future though.

1. As for the numbering, do we have a procedure to prevent this issue
in the future?
2. The provider is part of apache and I think the link
https://github.com/apache/terraform-provider-cloudstack should be
validated. What exactly is the objection to this?

On Mon, Apr 15, 2024 at 12:05 PM Rohit Yadav  wrote:
>
> All,
>
> The recent Terraform provider release v0.5.0 has a problem with the Terraform 
> registry website. 
> https://github.com/apache/cloudstack-terraform-provider/issues/109
>
> The registry support isn't able to provide a resolution now, their manual 
> resync button on the provider isn't fixing the issue.
>
> While I've documented the steps for manually installing and using the 
> provider. Most terraform/tofu users are used to consuming a provider from the 
> registry.
>
> If there are no objections, I propose that we just tag the current version as 
> v0.5.1 and push it on the registry for the purpose of publishing on the 
> registry website. We may need not do a formal vote for this as code wise 
> nothing has changed and we can make this tag to be a community release tag 
> solely done for the purpose of having a workaround on the registry website  
> https://registry.terraform.io/providers/cloudstack/cloudstack/latest which 
> gets published via 
> https://github.com/cloudstack/terraform-provider-cloudstack as the registry 
> also has a strict repo naming policy (due to which it can't use the repo 
> under Apache org).
>
> Thoughts?
>
> Regards.
>
>
>


--
Daan

Re: [DISCUSS] New terraform git tag for registry workaround

[Rohit Yadav]

All,

I got the following from TF support:


Hello there, provider versions are immutable in the registry. Therefore, when 
you deleted and recreated the version in Github, the hash has changed, and the 
registry will refuse to serve it. Your option now it either to delete the 
version in the registry (which we can help you do), or publish a new version.

I tried to get the release deleted from the registry, and republished the 
releases artifacts using goreleaser but still same issue.

I think the only thing to document is that we must never delete/republish an 
artifact on the release repo: 
http://github.com/cloudstack/terraform-provider-cloudstack

We cannot use the apache one as: (1) the registry needs the repo to be named as 
terraform-provider- and (2) it would need access from asf infra to 
connect registry with the repo, and it would then need existing users to 
migrate from cloudstack/cloudstack provider namespace (as the plugin has 
history/registry even before being donated to the cloudstack project).



Regards.

 



From: Harikrishna Patnala 
Sent: Tuesday, April 16, 2024 11:54
To: dev 
Subject: Re: [DISCUSS] New terraform git tag for registry workaround

okay, given the situation your proposal seems right Rohit. Like Daan asked, if 
we can prevent this situation in future we need to document it also.

Regards,
Harikrishna




From: Daan Hoogland 
Sent: Monday, April 15, 2024 4:50 PM
To: dev 
Subject: Re: [DISCUSS] New terraform git tag for registry workaround

I think your proposals are ok as an ad-hoc solution to the current
situation @Rohit Yadav . I wonder how we should deal with this in the
future though.

1. As for the numbering, do we have a procedure to prevent this issue
in the future?
2. The provider is part of apache and I think the link
https://github.com/apache/terraform-provider-cloudstack should be
validated. What exactly is the objection to this?

On Mon, Apr 15, 2024 at 12:05 PM Rohit Yadav  wrote:
>
> All,
>
> The recent Terraform provider release v0.5.0 has a problem with the Terraform 
> registry website. 
> https://github.com/apache/cloudstack-terraform-provider/issues/109
>
> The registry support isn't able to provide a resolution now, their manual 
> resync button on the provider isn't fixing the issue.
>
> While I've documented the steps for manually installing and using the 
> provider. Most terraform/tofu users are used to consuming a provider from the 
> registry.
>
> If there are no objections, I propose that we just tag the current version as 
> v0.5.1 and push it on the registry for the purpose of publishing on the 
> registry website. We may need not do a formal vote for this as code wise 
> nothing has changed and we can make this tag to be a community release tag 
> solely done for the purpose of having a workaround on the registry website  
> https://registry.terraform.io/providers/cloudstack/cloudstack/latest which 
> gets published via 
> https://github.com/cloudstack/terraform-provider-cloudstack as the registry 
> also has a strict repo naming policy (due to which it can't use the repo 
> under Apache org).
>
> Thoughts?
>
> Regards.
>
>
>


--
Daan

[DISCUSS] New terraform git tag for registry workaround

[Rohit Yadav]

All,

The recent Terraform provider release v0.5.0 has a problem with the Terraform 
registry website. 
https://github.com/apache/cloudstack-terraform-provider/issues/109

The registry support isn't able to provide a resolution now, their manual 
resync button on the provider isn't fixing the issue.

While I've documented the steps for manually installing and using the provider. 
Most terraform/tofu users are used to consuming a provider from the registry.

If there are no objections, I propose that we just tag the current version as 
v0.5.1 and push it on the registry for the purpose of publishing on the 
registry website. We may need not do a formal vote for this as code wise 
nothing has changed and we can make this tag to be a community release tag 
solely done for the purpose of having a workaround on the registry website  
https://registry.terraform.io/providers/cloudstack/cloudstack/latest which gets 
published via https://github.com/cloudstack/terraform-provider-cloudstack as 
the registry also has a strict repo naming policy (due to which it can't use 
the repo under Apache org).

Thoughts?

Regards.

 

Re: ACS 4.16 - Change SystemVM template for CKS

[Rohit Yadav]

Benoit,

I haven't tested it but could work - worth testing. CAPC was tested on 
4.17/4.18+.


Regards.

 



From: benoit lair 
Sent: Thursday, April 11, 2024 17:09
To: us...@cloudstack.apache.org 
Cc: dev 
Subject: Re: ACS 4.16 - Change SystemVM template for CKS

Rohit,

It is possible to install  CAPC on a CS 4.16 ?

Le jeu. 11 avr. 2024 à 12:03, Rohit Yadav  a
écrit :

> Hi Benoit,
>
> The CKS feature has been improving over versions, I don't know if what
> you're trying to achieve is possible with it. Maybe try a different version
> of the data iso:
> http://download.cloudstack.org/cks/
>
> Alternatively, you can also have a look at the CAPC project:
> https://cluster-api-cloudstack.sigs.k8s.io
>
>
> Regards.
>
>
>
>
> 
> From: benoit lair 
> Sent: Thursday, April 11, 2024 14:16
> To: us...@cloudstack.apache.org ; dev <
> dev@cloudstack.apache.org>
> Subject: Re: ACS 4.16 - Change SystemVM template for CKS
>
> Any advices ?
>
> Best regards
>
> Le lun. 8 avr. 2024 à 16:53, benoit lair  a écrit :
>
> > I am opened to every alternatives of changing system vm templates
> > I just need to run K8s clyusters 1.28 with my CS 4.16 :)
> >
> > Le lun. 8 avr. 2024 à 16:52, benoit lair  a
> écrit :
> >
> >> Hello Folks,
> >>
> >> I am trying to install K8s cluster with community iso 1.28.4
> >> I am with a ACS 4.16.0 environment
> >> It seems K8S is not working out of the box with v > 1.23.3 due to
> >> containerd.io version
> >>
> >> I would like to release a template who will work with K8s > 1.23.3 on
> acs
> >> 4.16
> >> How can i tell CS to take another system vm template, avoiding to mess
> >> normal features with VR and VPC VR keeping the systemvm template issued
> >> with CS 4.16 ?
> >>
> >> I am with XCP-NG 8.2.1 in production
> >>
> >> Thanks for your help or advises
> >> Best regards,
> >> Benoit
> >>
> >
>

Re: [RESULT] [VOTE] Release Apache CloudStack Terraform Provider v0.5.0

[Rohit Yadav]

Thanks Kiran and all for the excellent release work.

There has been some issue with publishing the v0.5.0 on the Terraform registry, 
for this I've logged a support ticket with the TF Registry.

In the meanwhile, users can use the following to install the provider locally 
using artifacts from the Github release;
https://github.com/apache/cloudstack-terraform-provider?tab=readme-ov-file#installing-from-github-release
https://github.com/apache/cloudstack-terraform-provider/wiki#installing-from-github-release

Regards.
 



From: Kiran Chavala 
Sent: Tuesday, April 9, 2024 11:52
To: dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org 
Subject: [RESULT] [VOTE] Release Apache CloudStack Terraform Provider v0.5.0

Hi All

After more than 72 hours, the vote for CloudStack Terraform Provider v0.5.0 
*passes* with

5 PMC + 2 non-PMC votes.

+1 (PMC / binding)
5 persons (Rohit, Daan, Boris, Hari, Nux)

+1 (non binding)
2 persons (Jithin, Suresh)

0
none

-1
none

Thanks to everyone participating.

I will now prepare the release announcement to go out after 24-48 hours to give 
the mirrors time to catch up.

Regards,
Kiran Chavala

Re: ACS 4.16 - Change SystemVM template for CKS

[Rohit Yadav]

Hi Benoit,

The CKS feature has been improving over versions, I don't know if what you're 
trying to achieve is possible with it. Maybe try a different version of the 
data iso:
http://download.cloudstack.org/cks/

Alternatively, you can also have a look at the CAPC project: 
https://cluster-api-cloudstack.sigs.k8s.io


Regards.

 



From: benoit lair 
Sent: Thursday, April 11, 2024 14:16
To: us...@cloudstack.apache.org ; dev 

Subject: Re: ACS 4.16 - Change SystemVM template for CKS

Any advices ?

Best regards

Le lun. 8 avr. 2024 à 16:53, benoit lair  a écrit :

> I am opened to every alternatives of changing system vm templates
> I just need to run K8s clyusters 1.28 with my CS 4.16 :)
>
> Le lun. 8 avr. 2024 à 16:52, benoit lair  a écrit :
>
>> Hello Folks,
>>
>> I am trying to install K8s cluster with community iso 1.28.4
>> I am with a ACS 4.16.0 environment
>> It seems K8S is not working out of the box with v > 1.23.3 due to
>> containerd.io version
>>
>> I would like to release a template who will work with K8s > 1.23.3 on acs
>> 4.16
>> How can i tell CS to take another system vm template, avoiding to mess
>> normal features with VR and VPC VR keeping the systemvm template issued
>> with CS 4.16 ?
>>
>> I am with XCP-NG 8.2.1 in production
>>
>> Thanks for your help or advises
>> Best regards,
>> Benoit
>>
>

Re: New PMC member: Slavka Peleva

[Rohit Yadav]

Welcome aboard Slavka!

Regards.
 



From: Kiran Chavala 
Sent: Wednesday, April 10, 2024 6:16:00 PM
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: Re: New PMC member: Slavka Peleva

Congratulations Slavka!

Regards
Kiran

From: Nicolas Vazquez 
Date: Wednesday, 10 April 2024 at 6:01 PM
To: us...@cloudstack.apache.org , 
dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: Re: New PMC member: Slavka Peleva
Congratulations Slavka!

Regards,
Nicolas Vazquez


From: Rene Peinthor 
Date: Wednesday, 10 April 2024 at 09:13
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: Re: New PMC member: Slavka Peleva
:clap: Slavka!

Cheers,
Rene

On Wed, Apr 10, 2024 at 2:04 PM Suresh Kumar Anaparti <
sureshanapa...@apache.org> wrote:

> Congratulations Slavka!
>
> Regards,
> Suresh
>
> On Wed, Apr 10, 2024 at 4:41 PM Ivet Petrova 
> wrote:
>
> > Hello all,
> >
> > The Project Management Committee (PMC) for Apache CloudStack
> > has invited Slavka Peleva to become a PMC member and we are pleased
> > to announce that they have accepted.
> >
> > Slavka has contributed in the past and has shown effort to make the
> > project run smoothly
> >
> > Please join me in congratulating Slavka!
> >
> >
> > Best regards,
> >
> >
> >
> >
> >
>

New Committer: Kiran Chavala

[Rohit Yadav]

The Project Management Committee (PMC) for Apache CloudStack
has invited Kiran Chavala (kiranchavala) to become a committer and
we are pleased to announce that they have accepted.

Kiran has been a long time CloudStack contributor and has created
over a hundred issues on Github. Being a committer enables easier
contribution to the project and enable better productivity.

Please join me in congratulating Kiran!

Regards.

[ADVISORY] Apache CloudStack Security Releases 4.18.1.1 and 4.19.0.1

[Rohit Yadav]

Apache CloudStack security releases 4.18.1.1 and 4.19.0.1 address the
CVEs listed below. Affected users are recommended to upgrade their
CloudStack installations.

1. CVE-2024-29006: x-forwarded-for HTTP header parsed by default

Severity: moderate

Description:

By default the CloudStack management server honours the
x-forwarded-for HTTP header and logs it as the source IP of an API
request. This could lead to authentication bypass and other
operational problems should an attacker decide to spoof their IP
address this way.

Affected versions: Apache CloudStack 4.11.0.0 through 4.18.1.0, and 4.19.0.0

Credit: Yuyang Xiao  (finder)

https://www.cve.org/CVERecord?id=CVE-2024-29006

2. CVE-2024-29007: When downloading templates or ISOs, the management
server and SSVM follow HTTP redirects with potentially dangerous
consequences

Severity: moderate

Affected versions: Apache CloudStack 4.9.1.0 through 4.18.1.0, and 4.19.0.0

Description:

The CloudStack management server and secondary storage VM could be
tricked into making requests to restricted or random resources by
means of following 301 HTTP redirects presented by external servers
when downloading templates or ISOs. Users are recommended to upgrade
to version 4.18.1.1 or 4.19.0.1, which fixes this issue.

Credit: Yuyang Xiao  (finder)

https://www.cve.org/CVERecord?id=CVE-2024-29007

3. CVE-2024-29008: The extraconfig feature can be abused to load
hypervisor resources on a VM instance

Severity: critical

Affected versions: Apache CloudStack 4.14.0.0 through 4.18.1.0, and 4.19.0.0

Description:

A problem has been identified in the CloudStack additional VM
configuration (extraconfig) feature which can be misused by anyone who
has privilege to deploy a VM instance or configure settings of an
already deployed VM instance, to configure additional VM configuration
even when the feature is not explicitly enabled by the administrator.
In a KVM based CloudStack environment, an attacker can exploit this
issue to attach host devices such as storage disks, and PCI and USB
devices such as network adapters and GPUs, in a regular VM instance
that can be further exploited to gain access to the underlying network
and storage infrastructure resources, and access any VM instance disks
on the local storage.

Credit: Wei Zhou  (finder)

https://www.cve.org/CVERecord?id=CVE-2024-29008

--

Re: [VOTE] Release Apache CloudStack Terraform Provider v0.5.0

[Rohit Yadav]

+1 (binding)

Tested vm deployment using 0.5.0-pre.

Regards.
 



From: Kiran Chavala 
Sent: Tuesday, April 2, 2024 2:55:40 PM
To: dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org 
Subject: [VOTE] Release Apache CloudStack Terraform Provider v0.5.0

Hi ALL

I've created a CloudStack Terraform Provider v0.5.0 release, with the following 
artifacts up for a vote:

Git Branch and Commit SH:

https://github.com/cloudstack/terraform-provider-cloudstack

Commit: 7c682bf17bebf40837a30ebcca811fc7b8785a15

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

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

Vote will be open for 72 hours.

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, they can use this 0.5.0-pre build 
https://registry.terraform.io/providers/cloudstack/cloudstack/0.5.0-pre for 
testing purposes.
The binaries are here: 
https://github.com/apache/cloudstack-terraform-provider/releases/tag/v0.5.0-pre


Regards
Kiran Chavala

Re: [ANNOUNCE] Rene Peinthor as committer

[Rohit Yadav]

Congratulations Rene!

Regards.
 



From: Ruben Bosch 
Sent: Friday, March 29, 2024 2:30:51 PM
To: dev@cloudstack.apache.org 
Subject: Re: [ANNOUNCE] Rene Peinthor as committer

Congratulations Rene!

On Fri, Mar 29, 2024 at 9:12 AM Daan Hoogland 
wrote:

> devs and users,
>
> The PMC have asked Rene Peinthor to become a committer to the Apache
> CloudStack project and they  have accepted.
>
> Please join me in congratulating Rene.
>
> --
> Daan
>

[ANNOUNCE] Apache CloudStack CloudMonkey v6.4.0

[Rohit Yadav]

# Apache CloudStack CloudMonkey v6.4.0 Release

Apache CloudStack, proven as one of the most scalable, free and open
source cloud computing operating system for large scale private,
public, and hybrid clouds, today announced the availability of the
latest release of Apache CloudMonkey v6.4.0, the latest version of the
turnkey enterprise Cloud orchestration platform's command line
interface tool.

Apache CloudMonkey v6.4.0 is the latest maintenance release since the
previous v6.1.0 release in July 2020. CloudMonkey v6.4.0 can be used
both as an interactive shell and as a command line tool that
simplifies CloudStack configuration and management.

The release includes the following changes:
- Improve CLI mode usage and output handling
- Add support for http POST handling for password and user-data
- Optimise async API jobs polling
- Better interrupt handling of Ctrl+C to cancel on-going API request
but not crash cmk
- Remove unnecessary call to listApis (sync) when using CLI mode with
url, api key, secret key
- Updates inbuilt API precache to ACS v4.19

## Downloads and Documentation

The official source code for CloudMonkey v6.4.0 can be downloaded from
http://cloudstack.apache.org/downloads.html

The community-maintained builds are available at the project's Github
release page at:
https://github.com/apache/cloudstack-cloudmonkey/releases/tag/6.4.0

CloudMonkey's usage details are documented at
https://github.com/apache/cloudstack-cloudmonkey/wiki

--

[VOTE][RESULT] Release Apache CloudStack CloudMonkey 6.4.0 - RC1

[Rohit Yadav]

Hi All,

The vote for CloudStack CloudMonkey v6.4.0 *passes* with 5 PMC + 1
non-PMC votes.

+1 (PMC / binding)
5 persons (Boris, Harikrishna, Lucian, Wei, Nicolas)

+1 (non binding)
1 persons (Suresh)

0
none

-1
none

Thanks to everyone participating.

I will now prepare the release announcement to go out after 24 hours
to give the mirrors time to catch up. And I'll publish the Github
release as latest.

Regards,
Rohit Yadav

On Thu, 21 Mar 2024 at 16:08, Rohit Yadav  wrote:
>
> Hi All,
>
> I've created a v6.4.0 release of CloudMonkey, with the following
> artifacts up for a vote:
>
> Git Branch and commit SHA:
> https://github.com/apache/cloudstack-cloudmonkey/commit/df65df7cfe331c5af5d39743717e3d58df921a48
>
> Commit:
> df65df7cfe331c5af5d39743717e3d58df921a48
>
> GitHub pre-release (contains changelog,
> artifacts/binaries to test, checksums/usage details):
> https://github.com/apache/cloudstack-cloudmonkey/releases/tag/6.4.0
>
> Source release (checksums and signatures are available at the same location):
> https://dist.apache.org/repos/dist/dev/cloudstack/cloudmonkey-6.4.0/
>
> PGP release keys (signed using 5ED1E1122DC5E8A4A45112C2484248210EE3D884)
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> The vote will be open until 27th March, 2024.
>
> 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)
>
> Convenience binaries are available from here:
> https://github.com/apache/cloudstack-cloudmonkey/releases/tag/6.4.0
>
> Regards.

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

[Rohit Yadav]

All,

Reminder - cmk 6.4.0 RC1 is up for testing and voting.

Regards.
 



From: Rohit Yadav 
Sent: Thursday, March 21, 2024 4:08:29 PM
To: dev ; users 
Subject: [VOTE] Release Apache CloudStack CloudMonkey 6.4.0 - RC1

Hi All,

I've created a v6.4.0 release of CloudMonkey, with the following
artifacts up for a vote:

Git Branch and commit SHA:
https://github.com/apache/cloudstack-cloudmonkey/commit/df65df7cfe331c5af5d39743717e3d58df921a48

Commit:
df65df7cfe331c5af5d39743717e3d58df921a48

GitHub pre-release (contains changelog,
artifacts/binaries to test, checksums/usage details):
https://github.com/apache/cloudstack-cloudmonkey/releases/tag/6.4.0

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

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

The vote will be open until 27th March, 2024.

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)

Convenience binaries are available from here:
https://github.com/apache/cloudstack-cloudmonkey/releases/tag/6.4.0

Regards.

[ANNOUNCE] New PMC Chair & VP Apache CloudStack Project - Daniel Salvador

[Rohit Yadav]

All,

It gives me great pleasure to announce that the ASF board has
accepted CloudStack PMC resolution of Daniel Augusto Veronezi Salvador 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.

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

Best Regards,
Rohit Yadav

[VOTE] Release Apache CloudStack CloudMonkey 6.4.0 - RC1

[Rohit Yadav]

Hi All,

I've created a v6.4.0 release of CloudMonkey, with the following
artifacts up for a vote:

Git Branch and commit SHA:
https://github.com/apache/cloudstack-cloudmonkey/commit/df65df7cfe331c5af5d39743717e3d58df921a48

Commit:
df65df7cfe331c5af5d39743717e3d58df921a48

GitHub pre-release (contains changelog,
artifacts/binaries to test, checksums/usage details):
https://github.com/apache/cloudstack-cloudmonkey/releases/tag/6.4.0

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

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

The vote will be open until 27th March, 2024.

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)

Convenience binaries are available from here:
https://github.com/apache/cloudstack-cloudmonkey/releases/tag/6.4.0

Regards.

Re: [DISCUSS] Next cmk release

[Rohit Yadav]

All,

Since we haven't heard of any issue/feature requests and the ones in the 
current milestone are all done. I'll start a vote on this today.

https://github.com/apache/cloudstack-cloudmonkey/milestone/5

Thanks and regards.
 



From: Rohit Yadav 
Sent: Tuesday, January 30, 2024 15:06
To: dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org 
Subject: [DISCUSS] Next cmk release

All,

Anybody have any feature/improvements requests and bugs to report for the next 
cmk release? (RM/release timeline yet to be discussed/determined).

Please add them here - https://github.com/apache/cloudstack-cloudmonkey/issues


Regards.

Re: [PROPOSE] RM for Cloudstack Terraform Provider

[Rohit Yadav]

All,

Update - Terraform Registry support is looking into it, meanwhile they've done 
sometime to effect trigger to have the pre/alpha build available publicly now - 
https://registry.terraform.io/providers/cloudstack/cloudstack/0.5.0-pre

Please continue testing and help report any issues/regressions at 
https://github.com/apache/cloudstack-terraform-provider/issues


Regards.

 



From: Rohit Yadav 
Sent: Friday, March 15, 2024 18:34
To: dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org 
Subject: Re: [PROPOSE] RM for Cloudstack Terraform Provider

All,

Kiran is release manager for the next Terraform provider release (v0.5.0) but 
isn't a committer to have commit privileges to the upstream repo (something PMC 
can help into?).

To assist him, I've created a pre-RC (alpha) build for testing purposes and we 
encourage users to test and report regressions/bugs. The binaries are here: 
https://github.com/apache/cloudstack-terraform-provider/releases/tag/v0.5.0-pre

For some reason, Terraform registry isn't picking up the Github release from 
the 'cloudstack' org which is used because of Terraform registry's strict repo 
naming convention -
https://registry.terraform.io/providers/cloudstack/cloudstack/latest (which 
should pick release information from 
https://github.com/cloudstack/terraform-provider-cloudstack/releases/tag/v0.5.0-pre).
 I've logged a ticket with Hashicorp to look into the resync/sync issue.

In the meantime, users can use the following alpha/pre-rc builds for testing 
from:
https://registry.terraform.io/providers/shapeblue/cloudstack/latest
or, binaries from:
https://github.com/apache/cloudstack-terraform-provider/releases/tag/v0.5.0-pre

Users are welcome to report any regressions or issues here: 
https://github.com/apache/cloudstack-terraform-provider/issues


Thanks and regards,

Rohit & Kiran





From: Kiran Chavala 
Sent: Monday, March 4, 2024 17:29
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Subject: [PROPOSE] RM for Cloudstack Terraform Provider

Hi All,

Greetings

I'd like to propose and put myself forward as the release manager for v0.5.0 
release of  
cloudstack-terraform-provider(https://github.com/apache/cloudstack-terraform-provider)
  if no objections are there.


Since the last release of the cloudstack-terraform-provider (v0.4.0) was in 
2022. I am proposing to have the v0.5.0 as a quicker release.


I am also proposing the keep the scope of v0.5 release minimal and it should 
only contain minor improvements and bug fixes


Regarding timeline for the v0.5.0 release, I am targeting it by March 25th 2024.

We can have a alpha release of v0.5.0 by March 18th 2024 which allows the 
community users to test and report any issues.


After the v0.5 release we can spend some more time on adding new features and 
improvements to the cloudstack-terraform-provider and do a proper release of 
v0.6.0 in the coming months


Please ping me (@kiranchavala) on GitHub, in case you want to include any 
Issue/PR in the v0.5.0 release.

Please let me know if you have any thoughts/comments.



[1] 
https://github.com/apache/cloudstack-terraform-provider/compare/v0.4.0...main

[2] https://github.com/apache/cloudstack-terraform-provider/milestone/2

[3] https://github.com/apache/cloudstack-terraform-provider/issues





Regards
Kiran

Re: Re-Introduction

[Rohit Yadav]

Welcome back Sina!



Regards.

 



From: Nicolas Vazquez 
Sent: Monday, March 18, 2024 21:16
To: dev@cloudstack.apache.org 
Subject: Re: Re-Introduction

Welcome back Sina!

Regards,
Nicolas Vazquez


From: Sina Kashipazha 
Date: Sunday, 17 March 2024 at 18:10
To: dev 
Subject: Re-Introduction
Dear All,

My name is Sina Kashipazha, and you may remember me from my time at Leaseweb. I 
wanted to take this opportunity to reintroduce myself as I have recently joined 
ComplianceWise.

I work as a software engineer, where I've had the opportunity to engage with 
cloud computing technologies and expand my understanding of scalable solutions. 
While my programming repertoire includes JavaScript, Python, and Go, my primary 
strength lies in Java, which is the cornerstone of my skill set for tackling 
various projects. Beyond programming, my expertise extends into networking and 
containerization, equipping me with a comprehensive skill set to design and 
optimize sophisticated, scalable systems efficiently.

My first few months at ComplianceWise were very busy as I focused on adapting 
to my new role. Now that I am more settled, I am ready to take on new 
challenges and actively contribute to our community's projects once more.

I'm looking forward to re-engaging with you all and contributing to Apache 
CloudStack's success in any way I can. Please feel free to reach out if you 
have any PRs or issues you think I could help with.

Warmest regards,
Sina Kashipazha

Re: [PROPOSE] RM for Cloudstack Terraform Provider

[Rohit Yadav]

All,

Kiran is release manager for the next Terraform provider release (v0.5.0) but 
isn't a committer to have commit privileges to the upstream repo (something PMC 
can help into?).

To assist him, I've created a pre-RC (alpha) build for testing purposes and we 
encourage users to test and report regressions/bugs. The binaries are here: 
https://github.com/apache/cloudstack-terraform-provider/releases/tag/v0.5.0-pre

For some reason, Terraform registry isn't picking up the Github release from 
the 'cloudstack' org which is used because of Terraform registry's strict repo 
naming convention -
https://registry.terraform.io/providers/cloudstack/cloudstack/latest (which 
should pick release information from 
https://github.com/cloudstack/terraform-provider-cloudstack/releases/tag/v0.5.0-pre).
 I've logged a ticket with Hashicorp to look into the resync/sync issue.

In the meantime, users can use the following alpha/pre-rc builds for testing 
from:
https://registry.terraform.io/providers/shapeblue/cloudstack/latest
or, binaries from:
https://github.com/apache/cloudstack-terraform-provider/releases/tag/v0.5.0-pre

Users are welcome to report any regressions or issues here: 
https://github.com/apache/cloudstack-terraform-provider/issues


Thanks and regards,

Rohit & Kiran

 



From: Kiran Chavala 
Sent: Monday, March 4, 2024 17:29
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Subject: [PROPOSE] RM for Cloudstack Terraform Provider

Hi All,

Greetings

I'd like to propose and put myself forward as the release manager for v0.5.0 
release of  
cloudstack-terraform-provider(https://github.com/apache/cloudstack-terraform-provider)
  if no objections are there.


Since the last release of the cloudstack-terraform-provider (v0.4.0) was in 
2022. I am proposing to have the v0.5.0 as a quicker release.


I am also proposing the keep the scope of v0.5 release minimal and it should 
only contain minor improvements and bug fixes


Regarding timeline for the v0.5.0 release, I am targeting it by March 25th 2024.

We can have a alpha release of v0.5.0 by March 18th 2024 which allows the 
community users to test and report any issues.


After the v0.5 release we can spend some more time on adding new features and 
improvements to the cloudstack-terraform-provider and do a proper release of 
v0.6.0 in the coming months


Please ping me (@kiranchavala) on GitHub, in case you want to include any 
Issue/PR in the v0.5.0 release.

Please let me know if you have any thoughts/comments.



[1] 
https://github.com/apache/cloudstack-terraform-provider/compare/v0.4.0...main

[2] https://github.com/apache/cloudstack-terraform-provider/milestone/2

[3] https://github.com/apache/cloudstack-terraform-provider/issues





Regards
Kiran

Re: [VOTE] next version 20 instead of 4.20

[Rohit Yadav]

Joao,

Could you start a separate [DISCUSS] thread, this is because your proposal is 
important in the context of future of ACS releases, but different from what 
this voting thread is about.

There are no bylaw(s) on how many releases should be done in a year or have 
them done in a certain way; we have adopted a community-agreed guideline to 
have 1-2 major releases a year to ship new features to users (some find this 
faster; some find this slower still). I think there is scope of improving those 
guidelines. However, any committer or PMC (or even a contributor with 
committer/PMC support) should be able to volunteer and help lead a release as 
its release manager.


The current development and release model has over the years seen deprecation 
and removal of features and components, such as API components (awsapi), 
(legacy) UI and old/unmaintained plugins. This is usually done over a course of 
time and releases with some support building and documentation/advisory, to 
allow feedback from the community. For deprecating justified areas and 
reasonable components of CloudStack, we can still do it without a new release 
model.


I believe the imporant thing is to iterate a proposal that would be generally 
accepted and benefial for the larger community, and generaly not breaking 
CloudStack's userspace to the effect that it breaks users' automation, 
integration, systems and tooling that are built on top of CloudStack.


Regards.


From: João Jandre Paraquetti 
Sent: Thursday, March 14, 2024 23:49
To: dev@cloudstack.apache.org 
Subject: Re: [VOTE] next version 20 instead of 4.20

Hi all,

I know that this discussion has cooled off, but I think it's still
extremely relevant for the future of ACS. That being said, I have
another proposal for the versioning scheme. Instead of dropping the "X"
on our X.Y.Z.N, we can set a fixed schedule (that can be further
discussed) for the version changes:

- Every two years, we release a major version (X), which can contain
changes that break backward compatibility, such as (but not limited to):
removing unused/useless APIs, renaming APIs, and changing the default
behavior of features. These changes must be discussed with the devs and
be properly communicated to the community (via API deprecation, for
example) at least one minor version before the major release;
- Every semester, we release a minor version (Y) of the current major
(X) version, these can contain new features/APIs, as long as the
backward compatibility is maintained; also, feature/API deprecation
should happen on these versions;
- Every 2/3 months, we release patch versions (Z), that fix any bugs
that were released with the major and minor versions, these versions
should not contain any new features;
- In extreme cases (such as with security issues) we work on and release
security versions (N);

The proposed schedule is only a sketch that can be worked on. However I
believe that the project can benefit from:
1. A fixed release schedule;
2. A mechanism to introduce disruptive changes, so that the project can
evolve and not be chained to the same features/API/limitation/technical
debts forever.

Furthermore, having a schedule allows us to have a project roadmap, that
outlines the future deprecations, changes and big features.

Best Regards,

João Jandre.

On 3/6/24 07:11, Giles Sirett wrote:
> IMO - they are two different subjects.
> Everybody hopes that we'd never break API compatibility, but there may be a 
> situation at some point in the future where it may be required and we 
> fundamentally cant take a decision now that limits what the community may 
> want to do in 10 years time.  Irrespective of what numbering scheme is being 
> used, that would still be a massive decision to make *at the time* and I'd 
> expect a vibrant debate on doing so
>
>
> Yes, semantic is a well know agreed standard: giving consistency across lots 
> of different software - but there is absolutely nothing to say that 
> CloudStack HAS to stick to that convention (arguably, by removing the "4." , 
> we're coming away from that standard anyway)  Lots of software doesn’t use 
> semantic release versioning at all.
>
> As long as we have a consistent versioning scheme and are clear about it - it 
> doesn’t matter what scheme we use IMO
>
> As Paul says the "X" in X.Y.Z is  usually used as a simple way  to warn of 
> API disruptive changes  - but that warning can be given in other ways (in 
> documentation , a compatibility matrix, etc)  *If* it ever happened, we would 
> be using the first number for bothand  
> 
>
>
> Kind Regards
> Giles
>
>
>
>
> -Original Message-
> From: Rohit Yadav 
> Sent: Wednesday, March 6, 2024 4:54 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] next version 20 instead of 4.20
>
> Daniel, Daan, others,
>

Re: [PROPOSE] upgrade paths for 4.19 and 20

[Rohit Yadav]

I think it would be most likely that we work towards releasing 4.19.1 before 
4.20.0. Then, it would be sensible to have 4.19.0 -> 4.19.1 -> 4.20.0 upgrade 
path.


Regards.

 



From: Daan Hoogland 
Sent: Friday, March 8, 2024 14:50
To: dev 
Subject: [PROPOSE] upgrade paths for 4.19 and 20

devs,
currently we have an upgrade path for 4.19.0.0 to 4.19.1.0 in the 4.19 branch
in the main branch we have a 4.19.0.0 to (4.)20.0.0 upgrade path
merging fails because of this and allowing either or both in main will
cause main to fail (at least after upgrading)
If we are sure that 4.19.1 will be release and will be released before
20 we can move the main upgrade path to be from 4.19.1 to 20 (never
mind the 4. or not)
If we do not release a 4.19.1 (first) we will have to move the path
back to originate from 4.19.0

Is this a sane strategy for now?

If no-one objects I'll do the forward merge after the weekend.


--
Daan

Re: [VOTE] next version 20 instead of 4.20

[Rohit Yadav]

Daniel, Daan, others,

Could you explain why you’d break CloudStack’s rest-like APIs? Isn’t the 
intention of dropping the 4. as we may never see a 5.x that involves major 
changes involving API incompatibility?

Regards.
 



From: Guto Veronezi 
Sent: Wednesday, March 6, 2024 4:00:30 AM
To: dev@cloudstack.apache.org 
Subject: Re: [VOTE] next version 20 instead of 4.20

> By agreeing to drop the "4" I think we're effectively voting and agreeing 
> that we'll not be breaking APIs.
That is not what was discussed in the thread [1]. If we agree that we
will not break APIs, I am -1 on dropping the "4". We need to create a
protocol along with the proposal, otherwise, we will be subjective about
the topic and will be agreeing on something for different reasons.

[1] https://lists.apache.org/thread/yxxjzov5dqrfsogth6kcq2r0wn8rzljv

On 3/5/24 15:10, Paul Angus wrote:
> Hi Rohit, thank you
>
> So to recap;
>
> Semantic versioning goes (in our use):
>  .  .  . 
> 
>
> And as I understand it you're looking to go
>
>  .  . 
> Starting from 20
>
> I'd ask the question - are there any big/disruptive changes people would want 
> to bundle together to keep the semantic versioning and move to 5.x.y.z
>
> I'm assuming not, so the move proposed is to drop semantic versioning and 
> continue from 20, understanding that we would lose the mechanism to warn of 
> very disruptive changes (for what it's worth).
>
> I've no objection to it.  The issue was, that reading the thread, people had 
> different takes on what the change was, what would it do and what it meant. 
> And also incorrect understandings of semantic versioning.
>
> So, to be pedantic, and have a clearly defined vote, I'd change the vote to 
> something like "Drop semantic versioning and continue from 20".  And include 
> your explanation about moving to
>  .  . 
>
> I would be ok to +1 that ^^^
>
> -paul
>
> -Original Message-
> From: Rohit Yadav 
> Sent: Tuesday, March 5, 2024 4:02 PM
> To: dev@cloudstack.apache.org; us...@cloudstack.apache.org
> Subject: Re: [VOTE] next version 20 instead of 4.20
>
> As I understand Daan's vote proposal and from the previous discussion thread, 
> the current scheme that results in a release like 4.20.x.y would simply 
> become 20.a.b, wherein "a" is for maintenance release (counter, starting with 
> 0) and "b" is only used for security releases (counter, starting with 0).
>
> The voting thread is about "deciding to drop the 4 from our versioning 
> scheme", wherein the next CloudStack version would become "20" instead of 
> "4.20". By agreeing to drop the "4" I think we're effectively voting and 
> agreeing that we'll not be breaking APIs. Some other opensource projects have 
> done something similar too. Of course, this needs to be properly explained 
> and documented both by a blog article and on the project wiki.
>
> Paul - are you satisfied with the explanations and discussions, are you still 
> blocking this vote thead or do you want to reconsider your vote?
>
>
> Regards.
>
>
>
>
> 
> From: Paul Angus 
> Sent: Tuesday, February 20, 2024 15:55
> To: dev@cloudstack.apache.org 
> Cc: us...@cloudstack.apache.org 
> Subject: RE: [VOTE] next version 20 instead of 4.20
>
> Hi Daan,
>
>
>  From our wiki page:
>
> -- Quote
> For those that may not be familiar with Semantic Versioning, the number 
> format is: X.Y.Z, where X is the major version, Y is the minor version, Z is 
> the patch number. The community strives to ensure backward API compatibility 
> within each major version (i.e.: code written against the CloudStack 
> 4.0.0-incubating API should work with all future 4.y.z versions). The 
> community may decide to increment the major version number in situations 
> where underlying implementation details require a cloud operator to face 
> significant challenges in upgrading from one version to the next. This should 
> be rare situation.
>
> In practice, feature releases will normally be an increment of the minor 
> version number of the project. Feature releases that break backward 
> compatibility will cause the major version number to be incremented. Bug fix 
> releases will never increment anything except the patch number.
> -- End quote.
>
>
> Specifically:
> The community may decide to increment the major version number in situations 
> where underlying implementation details require a cloud operator to face 
> significant challenges in upgrading from one version to the next. This should 
> be rare situation.
>
>
>  From this I can't see how we have broken the v

Re: [VOTE] next version 20 instead of 4.20

[Rohit Yadav]

As I understand Daan's vote proposal and from the previous discussion thread, 
the current scheme that results in a release like 4.20.x.y would simply become 
20.a.b, wherein "a" is for maintenance release (counter, starting with 0) and 
"b" is only used for security releases (counter, starting with 0).

The voting thread is about "deciding to drop the 4 from our versioning scheme", 
wherein the next CloudStack version would become "20" instead of "4.20". By 
agreeing to drop the "4" I think we're effectively voting and agreeing that 
we'll not be breaking APIs. Some other opensource projects have done something 
similar too. Of course, this needs to be properly explained and documented both 
by a blog article and on the project wiki.

Paul - are you satisfied with the explanations and discussions, are you still 
blocking this vote thead or do you want to reconsider your vote?


Regards.

 



From: Paul Angus 
Sent: Tuesday, February 20, 2024 15:55
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: RE: [VOTE] next version 20 instead of 4.20

Hi Daan,


From our wiki page:

-- Quote
For those that may not be familiar with Semantic Versioning, the number format 
is: X.Y.Z, where X is the major version, Y is the minor version, Z is the patch 
number. The community strives to ensure backward API compatibility within each 
major version (i.e.: code written against the CloudStack 4.0.0-incubating API 
should work with all future 4.y.z versions). The community may decide to 
increment the major version number in situations where underlying 
implementation details require a cloud operator to face significant challenges 
in upgrading from one version to the next. This should be rare situation.

In practice, feature releases will normally be an increment of the minor 
version number of the project. Feature releases that break backward 
compatibility will cause the major version number to be incremented. Bug fix 
releases will never increment anything except the patch number.
-- End quote.


Specifically:
The community may decide to increment the major version number in situations 
where underlying implementation details require a cloud operator to face 
significant challenges in upgrading from one version to the next. This should 
be rare situation.


From this I can't see how we have broken the versioning.  Have we introduced 
anything that meets the criteria above?  Again, the term 'minor version' is an 
unfortunate one because it makes it sound like it wouldn’t contain big new 
features.  However, that isn't the case, it can and should.

Also, I'd like to see fully laid out for the next few versions, how versioning 
is proposed to work, and what each part of x.y.z.n is then going to denote.

- Paul

-Original Message-
From: Daan Hoogland 
Sent: Tuesday, February 20, 2024 10:05 AM
To: us...@cloudstack.apache.org
Cc: dev@cloudstack.apache.org
Subject: Re: [VOTE] next version 20 instead of 4.20

Vivek, we could, but the main idea is that we repair our versioning system and 
make clear how we are actually dealing with our current system, which is major 
- new , possibly breaking features minor - improvements and enhancements tiny - 
urgent (security) fixes

and in addition we would go to 20 to indicate that is the follower of
4.19 not of 4. Someone may implement a new cloudstack (cloudstack5 for
instance) but this would not have anything to do with our current versioning 
system.

On Tue, Feb 20, 2024 at 5:06 AM Vivek Kumar  
wrote:
>
> Why not 5.0 ? Then it will be like 5.1, 5.2 in the future.  Just asking ..!
>
>
> > On 19-Feb-2024, at 10:49 PM, Paul Angus  wrote:
> >
> > Hi Daan,
> >
> > Can you clarify what we are actually voting on please.
> >
> > In thread that is linked I've seen:
> >
> > "[the vote] will be to adjust to the semantic versioning system."
> > - you can't go to 20 AND keep semantic versioning. The act of going to 20 
> > breaks semantic versioning [1].
> >
> > " drop the 4 at version 20 and continue as usual with minor and patch level 
> > updates as we have in the past."
> > - what's supposed to come next ? in lieu of what would have been 4.21 will 
> > it be 21 ?  is it going to be 20.1 then 20.2 ?
> >
> > From the thread and how people are referring to 'minor versions', there is 
> > a misunderstanding as to what semantic versioning means. For our project 
> > its explained here [1].   Major versions meaning "probably going to break a 
> > load of people's stuff', with minor versions not breaking stuff (at least 
> > not on purpose). So I get calling them minor versions really underplays the 
> > changes it can hold.
> >
> >
> > I'm going to stick in a -1.  Not as hard 'no' to any changes, but I think 
> > the vote should be on 'A change to the version numbering scheme' and then 
> > what is proposed properly laid out.
> >
> >
> >
> >
> > [1]   https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases 
> > (section on 

Re: [PROPOSE] RM for Cloudstack Terraform Provider

[Rohit Yadav]

Thanks for stepping up and sharing your plan.

Regards.
 



From: Suresh Kumar Anaparti 
Sent: Monday, March 4, 2024 5:36:55 PM
To: us...@cloudstack.apache.org 
Cc: dev@cloudstack.apache.org 
Subject: Re: [PROPOSE] RM for Cloudstack Terraform Provider

+1, on the timelines.

Nice to see terraform provider release after a long time, thanks for
volunteering Kiran!

Regards,
Suresh

On Mon, Mar 4, 2024 at 5:30 PM Kiran Chavala 
wrote:

> Hi All,
>
> Greetings
>
> I'd like to propose and put myself forward as the release manager for
> v0.5.0 release of  cloudstack-terraform-provider(
> https://github.com/apache/cloudstack-terraform-provider)  if no
> objections are there.
>
>
> Since the last release of the cloudstack-terraform-provider (v0.4.0) was
> in 2022. I am proposing to have the v0.5.0 as a quicker release.
>
>
> I am also proposing the keep the scope of v0.5 release minimal and it
> should only contain minor improvements and bug fixes
>
>
> Regarding timeline for the v0.5.0 release, I am targeting it by March 25th
> 2024.
>
> We can have a alpha release of v0.5.0 by March 18th 2024 which allows the
> community users to test and report any issues.
>
>
> After the v0.5 release we can spend some more time on adding new features
> and improvements to the cloudstack-terraform-provider and do a proper
> release of v0.6.0 in the coming months
>
>
> Please ping me (@kiranchavala) on GitHub, in case you want to include any
> Issue/PR in the v0.5.0 release.
>
> Please let me know if you have any thoughts/comments.
>
>
>
> [1]
> https://github.com/apache/cloudstack-terraform-provider/compare/v0.4.0...main
>
> [2] https://github.com/apache/cloudstack-terraform-provider/milestone/2
>
> [3] https://github.com/apache/cloudstack-terraform-provider/issues
>
>
>
>
>
> Regards
> Kiran
>
>
>
>

Re: new committer: Vishesh Jindal (vishesh)

[Rohit Yadav]

Congratulations Vishesh!

Regards.
 



From: Daman Arora 
Sent: Monday, February 26, 2024 8:59:37 PM
To: dev@cloudstack.apache.org 
Subject: Re: new committer: Vishesh Jindal (vishesh)

Congrats Vishesh!

On Mon, Feb 26, 2024, 10:29 a.m. Ruben Bosch  wrote:

> Congratulations Vishesh!
>
> On Mon, Feb 26, 2024 at 4:06 PM Nicolas Vazquez <
> nicolas.vazq...@shapeblue.com> wrote:
>
> > Congratulation Vishesh!
> >
> > Regards,
> > Nicolas Vazquez
> >
> >
> > From: Daan Hoogland 
> > Date: Monday, 26 February 2024 at 11:05
> > To: users , dev 
> > Subject: new committer: Vishesh Jindal (vishesh)
> > users and devs,
> >
> > The Project Management Committee (PMC) for Apache CloudStack
> > has invited Vishesh Jindal to become a committer and we are pleased
> > to announce that they have accepted.
> >
> > 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.
> >
> > Please join me in congratulating Vishesh.
> >
> > --
> > on behalf of the PMC, Daan
> >
> >
> >
> >
>

Re: [VOTE] next version 20 instead of 4.20

[Rohit Yadav]

+1



Regards.

 



From: m...@swen.io 
Sent: Monday, February 19, 2024 18:29
To: 'dev' 
Subject: AW: [VOTE] next version 20 instead of 4.20

+1

-Ursprüngliche Nachricht-
Von: Daan Hoogland 
Gesendet: Montag, 19. Februar 2024 13:50
An: dev 
Cc: users 
Betreff: [VOTE] next version 20 instead of 4.20

LS,

This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted 
please reply to dev@.

As discussed in [1] we are deciding to drop the 4 from our versioning scheme. 
The result would be that the next major version will be 20 instead of 4.20, as 
it would be in a traditional upgrade. As 20 > 4 and the versions are processed 
numerically there are no technical impediments.

+1 agree (next major version as 20
0 (no opinion)
-1 disagree (keep 4.20 as the next version, give a reason)

As this is a lazy consensus vote any -1 should be accompanied with a reason.

[1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87

--
Daan

Re: [PROPOSAL] version naming : drop the 4.

[Rohit Yadav]

(+ users)

All,

Generally speaking, any versioning/styling change can be perceived as a big or 
concerning change by users (those existing or new ones trying/adopting). So, we 
must get our message across properly and correctly.

I'm not for or against cosmetics change in versioning, but I'm really keen if 
we want to discuss if we can use this opportunity to streamline our LTS 
release, improve how we upgrade CloudStack (i.e relook at our DB/upgrade 
approach), make releases more linear and faster (avoid forking branches for 
example), and try to change new defaults and drop some old API/arch things 
(such as default API response type to json, but largely be backward 
compatible). Some of these suggestions may be too large an undertaking and make 
not be worth it.


Overall, I've no objections if the consensus is to drop the "4." version 
prefix. I also want to hear from our users if they've any feedback for us.


Regards.

 



From: Guto Veronezi 
Sent: Tuesday, February 13, 2024 18:34
To: dev@cloudstack.apache.org 
Subject: Re: [PROPOSAL] version naming : drop the 4.

Daan,

As we still plan to introduce disruptive changes (in a cautious and
structured way) in the major versions, all my concerns are met; I do not
have further technical reasons to keep the "4.".

Best regards,
Daniel Salvador (gutoveronezi)

On 2/12/24 11:55, Daan Hoogland wrote:
> bump,
> @Daniel Salvador is there any technical reason to keep the 4? any
> reason why there must be a 5 instead of a 21, 22 or 23? We are
> maintaining 4 number semantic versioning for no reason, as I see it.
>
> On Tue, Jan 30, 2024 at 12:02 PM Daan Hoogland  
> wrote:
>> Daniel, "technical" reasons for dropping the 4 are all in the field of
>> social engineering. In practice (as I think Wei also described) we are
>> already treating the "minor" version number as major version. Since
>> 4.0 or 4.1 (don´t remember) there has been renewed talk of a 5 , but
>> never enough reason and or commitment to make it real. We could argue
>> about it a lot.
>>
>> so
>> ¨¨¨
>> The main point is: *we have to understand the technical reasons for
>> the proposal and what we expect from it before deciding anything.
>> ¨¨¨
>> The most important point is that we expect that people understand that
>> we treat the number that now seems to be "minor" as major release
>> numbers.
>>
>>
>> On Fri, Jan 26, 2024 at 7:42 PM Wei ZHOU  wrote:
>>> Hi Daniel,
>>>
>>> If we are discussing 5.0, I would have the same concern as you.
>>> What we are discussing is dropping 4.x. The fact is, we will never release
>>> 5.0 (anyone disagree ?)
>>> In this case, the major version 4.x becomes useless.
>>> If we compare 4.20.0/4.21.0 with 20.0/21.0, it is obvious which is better.
>>> IMHO due to the similar reason, the Java version has been changed from 1.x
>>> to java 1.7/1.8 (=java 7/8) then to java 11/14/17.
>>> of course there will be some issues if semantic changes, I think it is
>>> under control.
>>>
>>>
>>>
>>> Regarding the compatibility, I think we can change the APIs gradually.
>>> I noticed the following recently when I tested VR upgrade to
>>> debian12/python3
>>>
>>> root@r-431-VM:~# python
>>> Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux
>>> Type "help", "copyright", "credits" or "license" for more information.
>> import cgi
>>> :1: DeprecationWarning: 'cgi' is deprecated and slated for removal
>>> in Python 3.13
>>>
>>> For the API changes you mentioned, we could try the similar
>>> - in version X, add new APIs, mark the old APIs as deprecated
>>> - tell users the old APIs will be removed in version Y, please use new APIs
>>> instead.
>>> - in version Y, remove the old APIs.
>>>
>>> This can be done in each major/minor release. No need to wait for 5.0.
>>>
>>>
>>> -Wei
>>>
>>> On Fri, 26 Jan 2024 at 18:51, Guto Veronezi  wrote:
>>>
 Exactly, so you understand now why we must discuss what we intend.
 Although, incompatibilities are needed sometimes so we can evolve,
 leaving old ways and deprecated technologies and techniques in the past.

 *The main point is: *we have to understand the technical reasons for the
 proposal and what we expect from it before deciding anything.

 Best regards,
 Daniel Salvador (gutoveronezi)



>>
>>
>> --
>> Daan
>
>

Re: [PROPOSE] RM for 4.19.1.0

[Rohit Yadav]

Thanks for volunteering Suresh. Agree as Daan has mentioned, community would 
benefit to have the 4.18.2.0 first with some gap to then have 4.19.1.0. The 
4.19.1 RC by May end or early June LGTM.

Regards.
 



From: Daan Hoogland 
Sent: Monday, February 12, 2024 5:25:44 PM
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: Re: [PROPOSE] RM for 4.19.1.0

no worries as João proposed to release 4.18.2 in march, but let's
make sure we have a good period between the two.

On Mon, Feb 12, 2024 at 12:50 PM Suresh Anaparti
 wrote:
>
> Hi All,
>
> CloudStack 4.19.0.0 is the latest LTS release. There are already some open 
> issues [1]  and pull requests [2] targeted for 4.19.1.0 [3] release.
>
> I'd like to propose and put myself forward as the release manager for 
> 4.19.1.0 if no objections there. Please ping me (@sureshanaparti) on GitHub, 
> in case you want to include any Issue/PR in 4.19.1.0.
>
> I propose to have a window of at least 8 weeks (2 months), which allows the 
> community / users to test, use 4.19.0.0 and report any issues. We can aim to 
> cut RC1 in Q2 2024 (maybe, sometime in May-2024). I'll propose the timeline 
> details soon. I hope to have your support.
>
> Please let me know if you have any thoughts/comments.
>
> [1] 
> https://github.com/apache/cloudstack/issues?q=is%3Aopen+is%3Aissue+milestone%3A4.19.1.0
> [2] 
> https://github.com/apache/cloudstack/pulls?q=is%3Apr+milestone%3A4.19.1.0+is%3Aopen
> [3] https://github.com/apache/cloudstack/milestone/31
>
>
> Regards,
> Suresh
>
>
>


--
Daan

Re: [DISCUSS][PROPOSAL] web site publishing procedure

[Rohit Yadav]

Thanks Daan,

LGTM - though, if website isn't going to get too many activity and updates 
(except for couple of blogs a month), we may simplify publishing from main in 
future.


Regards.

 



From: Daan Hoogland 
Sent: Thursday, February 8, 2024 17:39
To: dev 
Cc: PMC 
Subject: [DISCUSS][PROPOSAL] web site publishing procedure

devs (and PMC),

I created a procedure based on a staging->production promotion of PRs.
it is described in the readme file [1]

I went ahead and created it as we didn't have anything before. That
does not mean I get to decide on my own, so please add your unsalted
comment or create/add change proposals in the www issues [2]

This has been kind of attic work coming out at the last moment, please
forgive me someday. I am open to all changes to it.

[1] 
https://github.com/apache/cloudstack-www?tab=readme-ov-file#publishing-procedure
[2] https://github.com/apache/cloudstack-www/issues/new/choose

--
Daan

Re: Discussion: CloudStack upgrade to JRE17 and Debian12/python3

[Rohit Yadav]

Hi Wei,

Sorry I'm not sure if we're keeping 512 or not, referring to Lucian's point 
""but the slightest memory leak or a temporarily spiky conntrack table could 
derail it." - for this reason it's better to keep 512 even if 384 may be good 
enough.


Regards.

 



From: Wei ZHOU 
Sent: Monday, February 12, 2024 13:00
To: Rohit Yadav 
Cc: dev 
Subject: Re: Discussion: CloudStack upgrade to JRE17 and Debian12/python3

Hi Rohit,

Thanks. I will revert the changes then. If the users think 512MB will lead to 
large memory consumption, they can
- Create a System Offering
- Update global setting router.service.offering to the uuid of the new offering.


-Wei


On Fri, 9 Feb 2024 at 16:15, Rohit Yadav 
mailto:rohit.ya...@shapeblue.com>> wrote:
I would advise we should move to 512 MiB.

Regards.






From: Wei ZHOU mailto:ustcweiz...@gmail.com>>
Sent: Friday, February 9, 2024 4:14:06 PM
To: Rohit Yadav mailto:rohit.ya...@shapeblue.com>>; 
dev mailto:dev@cloudstack.apache.org>>
Subject: Re: Discussion: CloudStack upgrade to JRE17 and Debian12/python3

Hi Rohit,

I tested the VRs of a VPC (with 2 tiers, LB, PF, etc) with different memory 
sizes. 384MB memory looks ok.

(1) 384 MB

root@r-601-VM:~# free -m
   totalusedfree  shared  buff/cache   available
Mem: 331 222  39   0 144 109
Swap:242   0 242

(2) 320MB

root@r-603-VM:~# free -m
   totalusedfree  shared  buff/cache   available
Mem: 267 214  45   0  80  53
Swap:242   0 242

(3) 512MB

root@r-604-VM:~# free -m
   totalusedfree  shared  buff/cache   available
Mem: 457 214  63   0 256 242
Swap:242   0     242




On Thu, 8 Feb 2024 at 15:15, Rohit Yadav 
mailto:rohit.ya...@shapeblue.com>> wrote:
Thanks Wei.

I think VR should be set to 512 (if memory consuming is above 300MB). SSVM and 
CPVM aren’t they already at 512-1024 MiB?

Regards.






From: Nux mailto:n...@li.nux.ro>>
Sent: Thursday, February 8, 2024 2:50:11 PM
To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org> 
mailto:dev@cloudstack.apache.org>>
Cc: Wei ZHOU mailto:ustcweiz...@gmail.com>>
Subject: Re: Discussion: CloudStack upgrade to JRE17 and Debian12/python3

+1 option 2 (Debian12).

I think we need to do a bit longer term testing before we decide on the
new RAM size for the VR.
384MB might be good to boot, but the slightest memory leak or a
temporarily spiky conntrack table could derail it.
..But yeah, need to be conscious of the overall memory overhead in large
clouds.

On 2024-02-08 07:44, Wei ZHOU wrote:
> Hi Rohit,
>
> Thanks for your reply.
>
> Indeed the memory consumption could be an issue, especially for the
> users
> who have thousands of virtual routers.
>
> I have tested the debian12 systemvm template several times. Every time
> I
> get an error "kernel panic"  if the memory is 256MiB (the current
> memory
> size of the default system offering for virtual routers).
> I have tested 320MiB, 384MiB, and 512 MiB. The VRs seem good. For
> stability, I have updated the PR to change the memory size of the
> default
> offering of virtual routers from 256 MiB to 384 MiB.
>
> The current default memory size of system vms (CPVM, SSVM) is 512 MiB,
> so
> they will not be impacted.
> Hope it has less impact on users.
>
>
> -Wei
>
>
> On Thu, 8 Feb 2024 at 08:30, Rohit Yadav 
> mailto:rohit.ya...@shapeblue.com>>
> wrote:
>
>> Hi Wei, all,
>>
>> Thanks for the thread, I've no objections to either of the options,
>> but
>> option2 is preferred as Debian 11 security will EOL mid of this year.
>> So,
>> if not in 4.20, eventually we'll need to migrate systemvmtemplate base
>> OS
>> to Debian 12 at some point in future.
>>
>> The bigger implication for users will be doubling of their memory
>> consumption in their env for VRs.
>>
>>
>> Regards.
>>
>>
>>
>>
>> 
>> From: Wei ZHOU mailto:ustcweiz...@gmail.com>>
>> Sent: Tuesday, February 6, 2024 17:33
>> To: dev mailto:dev@cloudstack.apache.org>>; users
>> mailto:us...@cloudstack.apache.org>>
>> Subject: Discussion: CloudStack upgrade to JRE17 and Debian12/python3
>>
>> Hi all,
>>
>> My colleagues and I are working on upgrading CloudStack to support the
>> more
>> recent JRE version, python version and Debian versi

Re: Discussion: CloudStack upgrade to JRE17 and Debian12/python3

[Rohit Yadav]

I would advise we should move to 512 MiB.

Regards.
 



From: Wei ZHOU 
Sent: Friday, February 9, 2024 4:14:06 PM
To: Rohit Yadav ; dev 
Subject: Re: Discussion: CloudStack upgrade to JRE17 and Debian12/python3

Hi Rohit,

I tested the VRs of a VPC (with 2 tiers, LB, PF, etc) with different memory 
sizes. 384MB memory looks ok.

(1) 384 MB

root@r-601-VM:~# free -m
   totalusedfree  shared  buff/cache   available
Mem: 331 222  39   0 144 109
Swap:242   0 242

(2) 320MB

root@r-603-VM:~# free -m
   totalusedfree  shared  buff/cache   available
Mem: 267 214  45   0  80  53
Swap:242   0 242

(3) 512MB

root@r-604-VM:~# free -m
   totalusedfree  shared  buff/cache   available
Mem: 457 214  63   0 256 242
Swap:242   0 242




On Thu, 8 Feb 2024 at 15:15, Rohit Yadav 
mailto:rohit.ya...@shapeblue.com>> wrote:
Thanks Wei.

I think VR should be set to 512 (if memory consuming is above 300MB). SSVM and 
CPVM aren’t they already at 512-1024 MiB?

Regards.






From: Nux mailto:n...@li.nux.ro>>
Sent: Thursday, February 8, 2024 2:50:11 PM
To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org> 
mailto:dev@cloudstack.apache.org>>
Cc: Wei ZHOU mailto:ustcweiz...@gmail.com>>
Subject: Re: Discussion: CloudStack upgrade to JRE17 and Debian12/python3

+1 option 2 (Debian12).

I think we need to do a bit longer term testing before we decide on the
new RAM size for the VR.
384MB might be good to boot, but the slightest memory leak or a
temporarily spiky conntrack table could derail it.
..But yeah, need to be conscious of the overall memory overhead in large
clouds.

On 2024-02-08 07:44, Wei ZHOU wrote:
> Hi Rohit,
>
> Thanks for your reply.
>
> Indeed the memory consumption could be an issue, especially for the
> users
> who have thousands of virtual routers.
>
> I have tested the debian12 systemvm template several times. Every time
> I
> get an error "kernel panic"  if the memory is 256MiB (the current
> memory
> size of the default system offering for virtual routers).
> I have tested 320MiB, 384MiB, and 512 MiB. The VRs seem good. For
> stability, I have updated the PR to change the memory size of the
> default
> offering of virtual routers from 256 MiB to 384 MiB.
>
> The current default memory size of system vms (CPVM, SSVM) is 512 MiB,
> so
> they will not be impacted.
> Hope it has less impact on users.
>
>
> -Wei
>
>
> On Thu, 8 Feb 2024 at 08:30, Rohit Yadav 
> mailto:rohit.ya...@shapeblue.com>>
> wrote:
>
>> Hi Wei, all,
>>
>> Thanks for the thread, I've no objections to either of the options,
>> but
>> option2 is preferred as Debian 11 security will EOL mid of this year.
>> So,
>> if not in 4.20, eventually we'll need to migrate systemvmtemplate base
>> OS
>> to Debian 12 at some point in future.
>>
>> The bigger implication for users will be doubling of their memory
>> consumption in their env for VRs.
>>
>>
>> Regards.
>>
>>
>>
>>
>> 
>> From: Wei ZHOU mailto:ustcweiz...@gmail.com>>
>> Sent: Tuesday, February 6, 2024 17:33
>> To: dev mailto:dev@cloudstack.apache.org>>; users
>> mailto:us...@cloudstack.apache.org>>
>> Subject: Discussion: CloudStack upgrade to JRE17 and Debian12/python3
>>
>> Hi all,
>>
>> My colleagues and I are working on upgrading CloudStack to support the
>> more
>> recent JRE version, python version and Debian version for the systemvm
>> template.
>> We already have made some changes, if you are interested, please
>> review the
>> pull request: https://github.com/apache/cloudstack/pull/8497
>>
>> Here are what we want to achieve in CloudStack 4.20
>>
>> *1. Upgrade CloudStack to run with JRE17.*
>>
>> Currently we use JRE11 to build the CloudStack packages starting in
>> 2020.
>> CloudStack mgmt servers/usage/kvm agents run with JRE11 as well.
>> However,
>> JRE11 is EOL in September 2023 [1].
>> In CloudStack 4.20, we will build CloudStack using JRE11 (because old
>> 4.17/4.18/4/19 systemvm template do not have JRE17 installed) , but
>> enforce
>> user to install JRE17 on mgmt server and kvm hosts when upgrade to
>> CloudStack 4.20
>> It requires a lot of changes to build CloudStack using JRE17,

Re: Discussion: CloudStack upgrade to JRE17 and Debian12/python3

[Rohit Yadav]

Thanks Wei.

I think VR should be set to 512 (if memory consuming is above 300MB). SSVM and 
CPVM aren’t they already at 512-1024 MiB?

Regards.
 



From: Nux 
Sent: Thursday, February 8, 2024 2:50:11 PM
To: dev@cloudstack.apache.org 
Cc: Wei ZHOU 
Subject: Re: Discussion: CloudStack upgrade to JRE17 and Debian12/python3

+1 option 2 (Debian12).

I think we need to do a bit longer term testing before we decide on the
new RAM size for the VR.
384MB might be good to boot, but the slightest memory leak or a
temporarily spiky conntrack table could derail it.
..But yeah, need to be conscious of the overall memory overhead in large
clouds.

On 2024-02-08 07:44, Wei ZHOU wrote:
> Hi Rohit,
>
> Thanks for your reply.
>
> Indeed the memory consumption could be an issue, especially for the
> users
> who have thousands of virtual routers.
>
> I have tested the debian12 systemvm template several times. Every time
> I
> get an error "kernel panic"  if the memory is 256MiB (the current
> memory
> size of the default system offering for virtual routers).
> I have tested 320MiB, 384MiB, and 512 MiB. The VRs seem good. For
> stability, I have updated the PR to change the memory size of the
> default
> offering of virtual routers from 256 MiB to 384 MiB.
>
> The current default memory size of system vms (CPVM, SSVM) is 512 MiB,
> so
> they will not be impacted.
> Hope it has less impact on users.
>
>
> -Wei
>
>
> On Thu, 8 Feb 2024 at 08:30, Rohit Yadav 
> wrote:
>
>> Hi Wei, all,
>>
>> Thanks for the thread, I've no objections to either of the options,
>> but
>> option2 is preferred as Debian 11 security will EOL mid of this year.
>> So,
>> if not in 4.20, eventually we'll need to migrate systemvmtemplate base
>> OS
>> to Debian 12 at some point in future.
>>
>> The bigger implication for users will be doubling of their memory
>> consumption in their env for VRs.
>>
>>
>> Regards.
>>
>>
>>
>>
>> 
>> From: Wei ZHOU 
>> Sent: Tuesday, February 6, 2024 17:33
>> To: dev ; users
>> 
>> Subject: Discussion: CloudStack upgrade to JRE17 and Debian12/python3
>>
>> Hi all,
>>
>> My colleagues and I are working on upgrading CloudStack to support the
>> more
>> recent JRE version, python version and Debian version for the systemvm
>> template.
>> We already have made some changes, if you are interested, please
>> review the
>> pull request: https://github.com/apache/cloudstack/pull/8497
>>
>> Here are what we want to achieve in CloudStack 4.20
>>
>> *1. Upgrade CloudStack to run with JRE17.*
>>
>> Currently we use JRE11 to build the CloudStack packages starting in
>> 2020.
>> CloudStack mgmt servers/usage/kvm agents run with JRE11 as well.
>> However,
>> JRE11 is EOL in September 2023 [1].
>> In CloudStack 4.20, we will build CloudStack using JRE11 (because old
>> 4.17/4.18/4/19 systemvm template do not have JRE17 installed) , but
>> enforce
>> user to install JRE17 on mgmt server and kvm hosts when upgrade to
>> CloudStack 4.20
>> It requires a lot of changes to build CloudStack using JRE17, so it
>> will be
>> mostly like done in CloudStack 4.21 or later.
>>
>>
>> *2. Upgrade CloudStack VR to use python3*
>>
>> python2 is currently used in CloudStack VR, which is already EOL in
>> 2020
>> [2]. We must migrate to python3 as soon as possible.
>> All python scripts used in CloudStack VR will be migrated to python3.
>> If you use a Debian11 systemvm template (4.17/4.18/4.19), you need to
>> recreate or patch the System VMs and Virtual routers after upgrading
>> to
>> CloudStack 4.20.
>> If you choose to patch a System VM and Virtual router, two packages
>> will be
>> installed: python-is-python3 and python3-netaddr
>>
>>
>> *3. Upgrade CloudStack VR to Debian12*
>>
>> The more recent operating system provides more features and security.
>> This
>> is not urgent as Debian11 will be supported until 2026 [3].
>> We have tested the Debian12 systemvm templates, and found only two
>> issues
>> - OpenSSL has been upgraded from 1.1.0 to 3.0 in Debian12. Some
>> algorithms are deprecated. We have to set "@SECLEVEL=0" in apache2
>> config
>> and "PubkeyAcceptedAlgorithms=+ssh-rsa" to sshd config to support some
>> old
>> SSH keys and certificates.
>> - The current default memory size (256MB) of virtual routers is not
>> big
>> enough. The Debian docume

Re: Discussion: CloudStack upgrade to JRE17 and Debian12/python3

[Rohit Yadav]

Hi Wei, all,

Thanks for the thread, I've no objections to either of the options, but option2 
is preferred as Debian 11 security will EOL mid of this year. So, if not in 
4.20, eventually we'll need to migrate systemvmtemplate base OS to Debian 12 at 
some point in future.

The bigger implication for users will be doubling of their memory consumption 
in their env for VRs.


Regards.

 



From: Wei ZHOU 
Sent: Tuesday, February 6, 2024 17:33
To: dev ; users 
Subject: Discussion: CloudStack upgrade to JRE17 and Debian12/python3

Hi all,

My colleagues and I are working on upgrading CloudStack to support the more
recent JRE version, python version and Debian version for the systemvm
template.
We already have made some changes, if you are interested, please review the
pull request: https://github.com/apache/cloudstack/pull/8497

Here are what we want to achieve in CloudStack 4.20

*1. Upgrade CloudStack to run with JRE17.*

Currently we use JRE11 to build the CloudStack packages starting in 2020.
CloudStack mgmt servers/usage/kvm agents run with JRE11 as well. However,
JRE11 is EOL in September 2023 [1].
In CloudStack 4.20, we will build CloudStack using JRE11 (because old
4.17/4.18/4/19 systemvm template do not have JRE17 installed) , but enforce
user to install JRE17 on mgmt server and kvm hosts when upgrade to
CloudStack 4.20
It requires a lot of changes to build CloudStack using JRE17, so it will be
mostly like done in CloudStack 4.21 or later.


*2. Upgrade CloudStack VR to use python3*

python2 is currently used in CloudStack VR, which is already EOL in 2020
[2]. We must migrate to python3 as soon as possible.
All python scripts used in CloudStack VR will be migrated to python3.
If you use a Debian11 systemvm template (4.17/4.18/4.19), you need to
recreate or patch the System VMs and Virtual routers after upgrading to
CloudStack 4.20.
If you choose to patch a System VM and Virtual router, two packages will be
installed: python-is-python3 and python3-netaddr


*3. Upgrade CloudStack VR to Debian12*

The more recent operating system provides more features and security. This
is not urgent as Debian11 will be supported until 2026 [3].
We have tested the Debian12 systemvm templates, and found only two issues
- OpenSSL has been upgraded from 1.1.0 to 3.0 in Debian12. Some
algorithms are deprecated. We have to set "@SECLEVEL=0" in apache2 config
and "PubkeyAcceptedAlgorithms=+ssh-rsa" to sshd config to support some old
SSH keys and certificates.
- The current default memory size (256MB) of virtual routers is not big
enough. The Debian document says 780MB memory is required [4]. We have
tested that 512MB/384MB memory is enough. It also works if memory is 320MB.
But with 256MB, we got "kernel panic" when system VMs/VRs start.

The memory upgrade should not be a problem for most users. If users have
thousands of virtual routers, they might need to add more memory.
The new debian12 template might have an impact on CKS (cloudstack
kubernetes service).  Until now, we have not found any issue in our testing
with multiple hypervisors (ubuntu22/20, rocky8/alma8/ol8, alma9/ol9,
xenserver-71, vmware 67u3/70u3/80)


What's your opinion on the following two options ?

- Option 1: Upgrade to JRE17 and python3 (still use Debian11)
- Option 2: Upgrade to JRE17 and python3 and Debian12

Thank you !



[1] https://www.oracle.com/be/java/technologies/java-se-support-roadmap.html
[2] https://www.python.org/doc/sunset-python-2/
[3] https://wiki.debian.org/LTS
[4] https://www.debian.org/releases/bookworm/amd64/ch02s05.en.html

Re: [PROPOSE] ACS 4.18.2.0

[Rohit Yadav]

Hi Joao, all,

Given we’re only now more available after the major 4.19 release to work on 
other releases, could we reconsider the timeline and come up with an updated 
plan.

I think we should target early March to give us some space to work on the 
issues and PRs. Joao - I’m assuming you still want to be RM for the release, 
have you triaged the current issues and PRs to identify the must haves and good 
to haves for 4.18.2 ? And anyone else have any must have issues and PRs they 
want in 4.18?

Regards.

Regards.

From: João Jandre Paraquetti 
Sent: Monday, December 11, 2023 6:18:34 PM
To: dev@cloudstack.apache.org 
Subject: Re: [PROPOSE] ACS 4.18.2.0

I think we can push a week or two earlier on the proposed schedule, it
would look something like this:

   - From now till the final week of January (1.5 months): accept bug
fixes and minor improvements
   - First week of February: accept only blocker and critical bug fixes,
aiming to stabilize the branch.
   - Second week of February: start cutting RCs, vote and finish release
work.

What do you think?

Best regards,
João Jandre.

On 12/9/23 17:22, Rohit Yadav wrote:
> +1
>
> Given, 4.18 branch is benefitting from maintenance work already, I wouldn't 
> mind if you want to push it earlier to even say end of Jan, and target 
> release in Feb 2024.
>
>
> Regards.
>
> 
> From: João Jandre Paraquetti 
> Sent: Friday, December 8, 2023 23:32
> To: dev@cloudstack.apache.org 
> Subject: [PROPOSE] ACS 4.18.2.0
>
> Hi all,
>
> As suggested on the 4.20.0.0 discussion thread (see
> https://lists.apache.org/thread/nyoddmwydz2t59hsfs7gf0vozlf7n434), I'd
> like to propose the release of version 4.18.2.0 with myself as the RM,
> here's a rough timeline:
>
>- From now till the second week of February (2 months): accept bug
> fixes and minor improvements
>- Third week of February: accept only blocker and critical bug fixes,
> aiming to stabilize the branch.
>- End of February: start cutting RCs, vote and finish release work.
>
> We currently have 7 open PRs [1] and 51 open issues [2] with 4.18.2.0 as
> milestone, I believe the above timeline should give enough time to solve
> all concerns. In case anyone wants to include a bug fix or a pull
> request in 4.18.2.0 milestone, please mention me (JoaoJandre) on github.
>
> If anyone has any suggestions, please voice them.
>
> [1]:
> https://github.com/apache/cloudstack/pulls?q=is%3Apr+milestone%3A4.18.2.0+is%3Aopen
> [2]:
> https://github.com/apache/cloudstack/issues?q=is%3Aopen+is%3Aissue+milestone%3A4.18.2.0
>
> Best regards,
> João Jandre
>
>
>
>
>

 

Re: new website is life

[Rohit Yadav]

Fantastic! Great to see the new website finally go live after a decade, 
congratulations everybody!


Regards.

 



From: Daan Hoogland 
Sent: Wednesday, February 7, 2024 13:52
To: dev ; users 
Subject: new website is life

People,
we brought the new website. Please all have a look at
https://cloudstack.apache.org

thanks for any feedback

--
Daan

Re: [ANNOUNCEMENT] Apache CloudStack 4.19.0.0 LTS Release

[Rohit Yadav]

Congratulations everyone! Great work Abhishek and everyone involved in the 
release work.


Regards.

 



From: Abhishek Kumar 
Sent: Tuesday, February 6, 2024 17:06
To: dev@cloudstack.apache.org 
Subject: [ANNOUNCEMENT] Apache CloudStack 4.19.0.0 LTS Release

The Apache Software Foundation and the Apache CloudStack Project Announces
Apache® CloudStack® v4.19.

Apache CloudStack 4.19 is the most recent release of the cloud management
platform. It comes as a product of extensive contributions from the
development community and is a LTS release, guaranteeing ongoing
maintenance and support for a period of 18 months

The 4.19 release contains 314 new features, improvements and bug fixes
since 4.18, 26 of these being major features.

Some of the highlighted features include:

- VMware to KVM Migration

- KVM Import

- CloudStack Object Storage

- CloudStack DRS

- VNF Appliances Support

- Scheduled Instance Lifecycle Operations

- OAuth 2 Authentication

- CloudStack Snapshot Copy

The full list of new features can be found in the project release notes at:
https://docs.cloudstack.apache.org/en/4.19.0.0/releasenotes


The CloudStack documentation includes upgrade instructions from previous
versions of Apache CloudStack, and can be found at:
https://docs.cloudstack.apache.org/en/4.19.0.0/upgrading

The official installation, administration and API documentation for each of
the releases are available on our documentation page:
https://docs.cloudstack.apache.org/en/4.19.0.0/installguide

Downloads

The official source code for the 4.19.0.0 release can be downloaded from
our downloads page: https://cloudstack.apache.org/downloads.html

In addition to the official source code release, individual contributors
have also made convenience binaries available on the Apache CloudStack
download page, and can be found at:

- https://download.cloudstack.org/el/7/

- https://download.cloudstack.org/el/8/

- https://download.cloudstack.org/el/9/

- https://download.cloudstack.org/ubuntu/dists/

- https://www.shapeblue.com/cloudstack-packages/


Regards,

Abhishek

Re: [RESULT][VOTE] Apache CloudStack 4.19.0.0

[Rohit Yadav]

Thanks Abhishek and everyone involved in the effort.

And congratulations everyone !

Regards.
 



From: Abhishek Kumar 
Sent: Friday, February 2, 2024 5:48:54 PM
To: dev@cloudstack.apache.org ; users 

Subject: [RESULT][VOTE] Apache CloudStack 4.19.0.0

Hi all,

After more than 72 hours, the vote for CloudStack 4.19.0.0 *passes* with
7 PMC + 3 non-PMC votes.

+1 (PMC / binding)
* Daan
* Rohit
* Nicolas
* Nux
* Harikrishna
* Boris
* Wei


+1 (non binding)
* Vladimir
* Pearl
* Suresh

0
none

-1
none

Thanks to everyone participating.

I will now prepare the release announcement to go out after 24 hours to
give the mirrors time to catch up.

Regards,
Abhishek

Re: [VOTE] go life with new website(design)

[Rohit Yadav]

+1 (binding)



Regards.

 



From: Daan Hoogland 
Sent: Thursday, February 1, 2024 18:02
To: dev 
Subject: [VOTE] go life with new website(design)

LS,

I am not sure this is still needed after all the discussions
before,but I would like to start a lazy consent vote threat anyway
there are some non-blocking rest points mentioned and we can
administer those in the repo for the site [1]

so without further ado;
Do we want to go life with the website as staged in cloudstack.staged.apache.org

+1 yes
0 no opinion (no reaction suffices as well)
-1 no (please state reasons


[1] https://github.com/apache/cloudstack-www/issues/new/choose

Re: Introduction and Greetings

[Rohit Yadav]

Welcome Abhisar!


Regards.

 



From: Suresh Anaparti 
Sent: Wednesday, January 31, 2024 19:24
To: dev@cloudstack.apache.org 
Subject: Re: Introduction and Greetings

Welcome Abhisar!

Regards,
Suresh

From: Abhisar Sinha 
Date: Wednesday, 31 January 2024 at 6:12 PM
To: dev@cloudstack.apache.org 
Subject: Introduction and Greetings
Hi All,

I have background in Storage as a developer at NetApp India, and I have 
recently joined Shapeblue as a Software Engineer.
I am excited to be joining the CloudStack community and looking forward to 
interacting with the community and contributing to the project.

Thanks and Regards,
Abhisar

Re: [VOTE] Apache CloudStack 4.19.0.0 RC4

[Rohit Yadav]

+1 (binding)

Tested 4.19.0.0 RC4 packages with EL8 (Alma Linux) + KVM using mbx.

Tested the following:

Registered new template
Registered ssh public key
Created isolated network in VM deploy form
Deployed VM as root admin
Allow egress rules for isolated network
Created PF and FW rules, was able to ssh to instance and wget/ping Internet IPs

Created normal user account
Register ssh public key
Created isolated network in VM deploy form
Deployed VM as normal user with ssh key
Allow egress rules for isolated network
Acquire new public IP and SNAT that to the VM
Created FW rules, was able to ssh to instance and wget/ping Internet IPs

Found some UI quirks, issues, but none of them are blockers. Reported them 
here: https://github.com/apache/cloudstack/issues/8576


Regards.

 



From: Abhishek Kumar 
Sent: Monday, January 29, 2024 12:28
To: users ; dev@cloudstack.apache.org 

Cc: PMC 
Subject: [VOTE] Apache CloudStack 4.19.0.0 RC4

Hi All,

I've created a 4.19.0.0 release (RC4), with the following artifacts up for
a vote:

Git Branch and Commit SH:
https://github.com/apache/cloudstack/tree/4.19.0.0-RC20240129T1021
Commit: 2746225b999612f156e421199e34ef8de98a3664

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

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

For testing purposes, I have uploaded the different distro packages to:
http://download.cloudstack.org/testing/4.19.0.0-RC4/

Since 4.16 the system VM template registration is no longer mandatory
before upgrading, however, it can be downloaded from here if needed:
https://download.cloudstack.org/systemvm/4.19/

The vote will be open for 72 hours.

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)

Regards,
Abhishek

[DISCUSS] Next cmk release

[Rohit Yadav]

All,

Anybody have any feature/improvements requests and bugs to report for the next 
cmk release? (RM/release timeline yet to be discussed/determined).

Please add them here - https://github.com/apache/cloudstack-cloudmonkey/issues


Regards.

 

Re: CentOS 7 is reaching EOL

[Rohit Yadav]

Like we've done for EL6, starting some CloudStack release we'll need to 
consider the following for EL7:

- drop the EL7 packging support (this can be either from the next major release 
this year)
- change default smoketests against the next (EL8) as the new default
- fix our CI/CD to assume/use the new default (EL8)
- update our release notes, quick install guide for the new default
- add deprecation/EOL section in release notes compat matrix, and/or blog to 
EL7 users on how they can migrate


Regards.

 



From: Nux 
Sent: Wednesday, January 24, 2024 05:00
To: dev@cloudstack.apache.org 
Cc: Wei ZHOU 
Subject: Re: CentOS 7 is reaching EOL

Yes, I understood, that's what I was addressing. :)

On 2024-01-23 23:03, Wei ZHOU wrote:
> Hi Lucian,
>
> I think what Vishesh meant is removing the support of CentOS 7 as a
> management server or kvm host.
>
> -Wei
>
> On Tue, 23 Jan 2024 at 22:07, Nux  wrote:
>
>> I would not be so hasty. I am sure there are still CentOS 5 instances
>> in
>> existence somewhere, similarly I think CentOS 7 will not go down
>> without
>> a fight.
>> I'm not saying to never kill support for it, but I'd leave it maybe
>> 1-2
>> more releases. Corporate users especially will take a lot of time to
>> move...
>>
>> /imho
>>
>> On 2024-01-23 16:27, Vishesh Jindal wrote:
>> > Hi all
>> >
>> > While working on a PR[1] to upgrade JRE, I noticed that CentOS 7 is
>> > reaching end of life on 30 June, 2024 [2].
>> >
>> > Should we remove support for CentOS 7 after 4.19 is released? Because
>> > by the time 4.20 is out, CentOS 7 would already have reached its EOL
>> > and IMO it doesn't make sense to maintain support for it.
>> >
>> > Regards,
>> > Vishesh
>> >
>> >
>> > Ref:
>> > [1] https://github.com/apache/cloudstack/pull/8438
>> > [2] https://www.redhat.com/en/topics/linux/centos-linux-eol
>>

Re: [VOTE] drop first version number and continue with semantic versioning

[Rohit Yadav]

Agree with Daniel, I would prefer to discuss this further too. I think we're 
moving too fast with the voting.


Regards.

 



From: Guto Veronezi 
Sent: Thursday, January 25, 2024 20:25
To: dev@cloudstack.apache.org 
Subject: Re: [VOTE] drop first version number and continue with semantic 
versioning

Hello guys,

I just replied the discussion thread and I would like to discuss it a
little bit further before voting.

Best regards,
Daniel Salvador (gutoveronezi)

On 1/25/24 11:47, Daan Hoogland wrote:
> LS,
>
> As previously discussed [1] there is a growing wish to no longer carry
> the version number 4 in future versions. The proposal is to proceed as
> usual but just drop the first number. This means the next version will
> be called 20.0, in addition to a possible 4.18.2 and/or 4.19.1
>
> +1 for agree
> 0 for no strong opinion or objects either way
> -1 for disagree (add your reason to be counted)
>
> [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
>

Re: [VOTE] Apache CloudStack 4.19.0.0 RC3

[Rohit Yadav]

Thanks Abhishek and all involved for your hard work - it's not uncommon to 
create multiple RCs for a major .0 release - hope to get there with the next 
one.


Regards.


From: Abhishek Kumar 
Sent: Tuesday, January 23, 2024 18:55
To: users ; dev@cloudstack.apache.org 

Cc: PMC 
Subject: Re: [VOTE] Apache CloudStack 4.19.0.0 RC3

Hi all,

We have found an issue with RC3 which would cause regression for UEFI
functionality on KVM hosts and VM deployment.
We already have a pull request to fix it,
https://github.com/apache/cloudstack/pull/8547
I'll work with contributors and cut a new RC with this fix.

Regards,
Abhishek


 

On Mon, 22 Jan 2024 at 16:27, Abhishek Kumar  wrote:

> Hi All,
>
> I've created a 4.19.0.0 release (RC3), with the following artifacts up for
> a vote:
>
> Git Branch and Commit SH:
> https://github.com/apache/cloudstack/tree/4.19.0.0-RC20240122T1028
> Commit: 43066e4020cf48108e6d0bb125be7d24fc2d609f
>
> Source release (checksums and signatures are available at the same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.19.0.0/
>
> PGP release keys (signed using 65518106473A09D7AF26B384A70BD2EAA74E2866):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> For testing purposes, I have uploaded the different distro packages to:
> http://download.cloudstack.org/testing/4.19.0.0-RC3/
>
> Since 4.16 the system VM template registration is no longer mandatory
> before upgrading, however, it can be downloaded from here if needed:
> https://download.cloudstack.org/systemvm/4.19/
>
> The vote will be open for 72 hours.
>
> 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)
>
> Regards,
> Abhishek
>

Re: new website design

[Rohit Yadav]

+1 overall, but there are a few things I would consider blockers:

1.  the blog page doesn't look same as on current blog (prod).

https://cloudstack.staged.apache.org/blog (staging blog)

versus

https://cloudstack.apache.org/blog/ (current blog/prod.)

If we can fix the blog listing and the  that should be okay.

2. The colour of the buttons in some places are different shades of blue, for 
example on https://cloudstack.staged.apache.org the download/documentation 
button and scroll down, we see button with a violet/navy-blue shade. Minor css 
issue? I would expect button to match the theme, for example button colour as 
in https://cloudstack.apache.org/blog/india-user-group-2024

3. Fact check all pages, for example the staging landing says 4.18.0.0 is 
latest release and link/content around events. Before we migrate/transition, 
all data must be latest/accurate as possible.

4. Minor issue - the logo on the staging site's landing page, uses old 
dashboard, that could be replaced with what the latest/most-recent dashboard 
looks like.



Regards.


From: Sven Vogel 
Sent: Monday, January 22, 2024 18:30
To: dev@cloudstack.apache.org ; 
priv...@cloudstack.apache.org 
Cc: users 
Subject: Re: new website design

+1 looks nice

Am Montag, den 01/22/2024 um 11:46 schrieb Nux:



+1 - do it.

On 2024-01-19 14:50, Daan Hoogland wrote:
> As we get no major issues on it and we already voted to have this
> design applied, is it alright to deploy this in the coming weeks?
>
> On Wed, Jan 17, 2024 at 8:31 PM Daan Hoogland
> wrote:
>>
>> devs and users,
>>
>> back in august we had a small discussion about a new website
design,
>> led by Ivet [1]. In the meanwhile Rohit had investigated using
>> docusaurus as a publishing mechanism for the site. After the last
few
>> weeks I have been working on integrating the two. The result so far
>> can be viewed on the staging site [2]
>>
>> Please all have a look and give me any feedback you may have, so we
>> can move this forward.
>>
>> [1]
https://lists.apache.org/thread/fopjc3r4hjkp9nbkj9xzoxv406rowkso
>> [2] https://cloudstack.staged.apache.org/
>>
>> --
>> Daan

 

Re: Setup Linstor Plugin for ACS

[Rohit Yadav]

Hi,

I got my rough notes here; 
https://gist.github.com/rohityadavcloud/7844bfa8cbc9586408ce3596c71caa50

And there is a guide here - 
https://linbit.com/drbd-user-guide/linstor-guide-1_0-en


Regards.


From: Technology Rss 
Sent: Tuesday, January 23, 2024 12:40
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Subject: Setup Linstor Plugin for ACS

Hello community!

I want to setup Linstorplugin for my ACS environment. Please let me know
any user experience for any issue for production uses.

Also please share any technical details for setup it.

--

*Thanks & Regards.*

*Support Admin*



*Facebook  | Twitter
 | YouTube
 | LinkedIn
*

*Address : *116/1 West Malibagh, D. I. T Road

Dhaka-1217, Bangladesh

*Mob :* +88 01716915504

*Email :* support.ad...@technologyrss.com

*Web :* www.technologyrss.com

 

Re: [PROPOSE] Upgrade JDK from 11 to 17

[Rohit Yadav]

Thanks Vishesh. Good initiative.

I think moving the codebase to build against JDK17 could be more work, than 
making cloudstack pkgs/builds work with JRE17. Given the next Debian release 
(12) only supports JRE17, the first step (maybe within scope of 4.20) could be 
to ensure that CloudStack can work with JRE17 and then slowly migrate 
buildsystems to use JDK17 (maybe within scope of 4.20 if effort permits, or 
with 4.21+). This should be possible as EL7/CentOS7 reached EOL around June 
this year, so we wouldn't have to support any distro that doesn't have JRE17 
pkgs.

I've started an investigative PR in this regard - 
https://github.com/apache/cloudstack/pull/8438


Regards.


From: Harikrishna Patnala 
Sent: Tuesday, January 2, 2024 17:35
To: dev@cloudstack.apache.org 
Subject: Re: [PROPOSE] Upgrade JDK from 11 to 17

Good start Vishesh. Thanks

Regards,
Harikrishna

From: Vishesh Jindal 
Date: Tuesday, 2 January 2024 at 2:39 PM
To: dev@cloudstack.apache.org 
Subject: [PROPOSE] Upgrade JDK from 11 to 17
Hi all,

Java 11 has already reached end of life, and the next LTS Java 17's EOL is in 
2027.

I have added a list of TODOs here: 
https://github.com/apache/cloudstack/issues/7686#issuecomment-1871844301
Let me know if I missed anything.

Upgrading some of the packages would require changes because of deprecations or 
new APIs which might take some time. I propose we start doing these changes in 
different PRs and upgrade to JDK17 in the next release (4.20). This will 
require considerable testing because of changes in the dependencies and the JDK 
itself.









 

Re: [PROPOSE] ACS 4.19.0.0 release

[Rohit Yadav]

Thanks Abhishek, looking forward to RC1.

Regards.

From: Abhishek Kumar 
Sent: Thursday, December 14, 2023 6:14:43 PM
To: dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org 
Subject: Re: [PROPOSE] ACS 4.19.0.0 release

Hi all,

I would like to announce the code freeze now.
From now onwards, we will only accept critical/blocker issues or any 
stabilization fixes. We have over 100 open items in the 4.19.0.0 milestone [1] 
at the moment. Most of them will be moved to the next milestone.
Currently, as reported yesterday there is one blocker issue [2]. We are working 
on a fix for the same. We may also need some stabilization concerning the 
integration test.
I expect support from all of you to work towards cutting RC1 in the coming week.

Regards,
Abhishek

[1] https://github.com/apache/cloudstack/milestone/24
[2] https://github.com/apache/cloudstack/issues/8352

From: Abhishek Kumar 
Sent: 13 December 2023 18:16
To: dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org 
Subject: Re: [PROPOSE] ACS 4.19.0.0 release

Hi all,

Due to some privately sent requests to postpone the code freeze, I propose 
postponing the code freeze date by a day.
Also, we already have a possible blocker [1] reported on the main branch so 
looking into getting that fixed.

I'll send an email tomorrow to announce the code freeze and will move the 
remaining open items to the next milestone.
We will still work towards cutting RC1 in the coming week.

Regards,
Abhishek

[1] https://github.com/apache/cloudstack/issues/8352



From: Abhishek Kumar 
Sent: 07 December 2023 18:02
To: dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org 
Subject: Re: [PROPOSE] ACS 4.19.0.0 release

Hi all,

To update you on the status of the 4.19.0.0 milestone [1], currently, we have 
nearly 127 open items in the milestone.
Many of them have not seen any update or progress lately so we will have to 
move them out of the milestone. Also, quite a few are now just waiting for 
integration test results or in the final phase.
Based on this, I would like to propose,

  *
Code freeze on the main branch starting 13 Dec 2023, accepting only 
critical/blocker issues (if any)
  *   Cut RC1 in the week of 18-24 Dec 2023

Please let me know your thoughts.

Also, if you have a PR/issue marked for the 4.19.0.0/4.18.2 milestone please 
keep an eye on any updates on it.
Some of us have also got our feature/improvements already merged but 
documentation for the same is still pending so kindly make sure to progress on 
that.

Regards,
Abhishek

[1] https://github.com/apache/cloudstack/milestone/24


From: Abhishek Kumar 
Sent: 21 November 2023 17:11
To: dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org 
Subject: Re: [PROPOSE] ACS 4.19.0.0 release

Hi all,

Thanks a lot Daan for cleaning up the 4.19.0.0 milestone [1].
Now we have around 123 open items in the milestone. We still have some 
interesting features and enhancements in progress.
In addition to this, we are seeing some recurring test failures on the PRs 
including health-check which would need some work.
Also, rest of this week a lot of us will be busy with CloudStack Collab 2023.
Considering these I propose moving the timeline to the following,

  *   Announce code freeze in early December 2023
  *   Cut RC1 thereafter in the first half of December 2023

Thank you for your understanding and support. Looking forward to meeting 
community folks in person in the next few days.


Regards,
Abhishek

[1] https://github.com/apache/cloudstack/milestone/24

From: Daan Hoogland 
Sent: 10 November 2023 15:22
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: Re: [PROPOSE] ACS 4.19.0.0 release

After consulting with Abhishek I have started to move PRs and issues out of
the 4.19 and 4.18.2 milestones. I think we are not going to make the dates
mentioned anyway but want to reduce the delay as much as possible.

Please be responsive on your PRs and issues if you want them in, I will not
touch the milestones of any item that has had activity in the last week.

hope you all forgive me one day,

On Thu, Oct 26, 2023 at 12:50 PM Abhishek Kumar <
abhishek.ku...@shapeblue.com> wrote:

> Hi all,
>
> Update on the current state of the 4.19.0.0 milestone. Currently, there
> are still 179 open items in the 4.19.0.0 milestone [1]. We still have many
> exciting new features which need some work in the form code-changes or
> review and testing.
> Also, there are some issues and PRs in 4.18.2.0 milestone [2] which are
> marked major in severity.
> Based on this I would like to propose moving the earlier suggested
> timeline further and the revised timeline can be,
>
> - Announce code freeze around mid of the next month, November 2023
> - RC1 can be expected thereafter in the second half of November 2023
>
> If you have got an active PR with 

Re: New Object Storage - Huawei OBS

[Rohit Yadav]

Hi Ronald,

If it helps, there are some CloudStack dev learning guide around how to create 
a plugin and manage dependencies: https://github.com/shapeblue/hackerbook

Looking forward to see your new object storage plugin (if you decide to 
contribute upstream).


Regards.


From: Ronald Feicht 
Sent: Thursday, December 14, 2023 17:00
To: dev@cloudstack.apache.org 
Subject: Re: New Object Storage - Huawei OBS

Hi,


I had added the module to client/pom.xml, but then 
http://192.168.17.252:8080/client/ retuns "HTTP ERROR 503 Service Unavailable" 
because of the following exception:

[WARNING] Failed startup of context 
o.e.j.m.p.JettyWebAppContext@1df8ea34{/client,file:///opt/cloudstack-huawei-obs/client/target/classes/META-INF/webapp/,UNAVAILABLE}{file:///opt/cloudstack-huawei-obs/client/target/classes/META-INF/webapp/}
java.lang.NullPointerException
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet$1.with
 (DefaultModuleDefinitionSet.java:104)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule
 (DefaultModuleDefinitionSet.java:263)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule
 (DefaultModuleDefinitionSet.java:268)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule
 (DefaultModuleDefinitionSet.java:268)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule
 (DefaultModuleDefinitionSet.java:268)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule
 (DefaultModuleDefinitionSet.java:268)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule
 (DefaultModuleDefinitionSet.java:268)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule
 (DefaultModuleDefinitionSet.java:251)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.startContexts
 (DefaultModuleDefinitionSet.java:96)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.load 
(DefaultModuleDefinitionSet.java:79)
at 
org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory.loadModules
 (ModuleBasedContextFactory.java:37)
at org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init 
(CloudStackSpringContext.java:70)
at 
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext. 
(CloudStackSpringContext.java:57)
at 
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext. 
(CloudStackSpringContext.java:61)
at 
org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener.contextInitialized
 (CloudStackContextLoaderListener.java:52)
at org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized 
(ContextHandler.java:933)
at org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized 
(ServletContextHandler.java:553)
at org.eclipse.jetty.server.handler.ContextHandler.startContext 
(ContextHandler.java:892)
at org.eclipse.jetty.servlet.ServletContextHandler.startContext 
(ServletContextHandler.java:356)
at org.eclipse.jetty.webapp.WebAppContext.startWebapp 
(WebAppContext.java:1445)
at org.eclipse.jetty.maven.plugin.JettyWebAppContext.startWebapp 
(JettyWebAppContext.java:328)
at org.eclipse.jetty.webapp.WebAppContext.startContext 
(WebAppContext.java:1409)
at org.eclipse.jetty.server.handler.ContextHandler.doStart 
(ContextHandler.java:825)
at org.eclipse.jetty.servlet.ServletContextHandler.doStart 
(ServletContextHandler.java:275)
at org.eclipse.jetty.webapp.WebAppContext.doStart (WebAppContext.java:524)
at org.eclipse.jetty.maven.plugin.JettyWebAppContext.doStart 
(JettyWebAppContext.java:397)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start 
(AbstractLifeCycle.java:72)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start 
(ContainerLifeCycle.java:169)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart 
(ContainerLifeCycle.java:117)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart 
(AbstractHandler.java:97)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start 
(AbstractLifeCycle.java:72)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start 
(ContainerLifeCycle.java:169)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart 
(ContainerLifeCycle.java:117)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart 
(AbstractHandler.java:97)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start 
(AbstractLifeCycle.java:72)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start 
(ContainerLifeCycle.java:169)
at org.eclipse.jetty.server.Server.start (Server.java:407)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart 
(ContainerLifeCycle.java:110)
at 

Re: new committer Vladimir Petrov

[Rohit Yadav]

Congratulations and well done Vladi !



Regards.


From: Nux 
Sent: Tuesday, December 12, 2023 15:27
To: us...@cloudstack.apache.org 
Cc: dev 
Subject: Re: new committer Vladimir Petrov

Well done, Vladi! :)

On 2023-12-12 09:52, Daan Hoogland wrote:
> community,
>
> The PMC has decided Vladi to become a committer and he has gracefully
> accepted. Please join me in welcoming Vladi to the project as
> committer.
> Congratulations Vladi

 

Re: Question about ObjectStoreDriver for implementing Ceph driver

[Rohit Yadav]

Hi Wido,

I think when the minio object storage plugin was written we didn’t have the 
limitations or foresight on how to structure the code, I would agree in 
refactoring the interface enough to allow what you’re trying to achieve.

Typically to a plugin you don’t want to pass database objects (Dao or VO) but a 
transform them as transfer object (TO) that doesn’t introduce dao or schema pkg 
dependencies to the plugin and TOs are kept as simple Java object. In the TO 
you can introduce fields and getters that suit your use cases.

Regards.

Regards.

From: Wido den Hollander 
Sent: Tuesday, December 12, 2023 1:28:56 AM
To: dev@cloudstack.apache.org ; kis...@apache.org 

Subject: Question about ObjectStoreDriver for implementing Ceph driver

Hi (Kishan),

I am making a first attempt [0] to implement a Ceph RGW [1] Object Store
Driver for CloudStack and I have a few questions about the code.

While implementing the Ceph RGW driver I have noticed that some methods
are provided the bucket's name (as a String) as an argument, but I'd
rather have a 'Bucket' object, for example:

public AccessControlList getBucketAcl(String bucketName, long storeId)
public boolean setBucketEncryption(String bucketName, long storeId)

In Ceph's case it would be better if these methods would get a Bucket
object, like:


public AccessControlList getBucketAcl(Bucket bucket, long storeId)

The reason is that I need to access the Account the bucket belongs to.
With Minio there is an 'Admin' client which allows you to do all these
operations as an Admin, but with Ceph there isn't. With Ceph you are
supposed to obtain the credentials (access + secret) via an Admin API
[2] and then execute these commands as the user.

Now, we have the access + secret key from the account recorded under the
account and we can access that from the Bucket object:

bucket.getAccessKey()
bucket.getSecretKey()

My proposal would be to change the signature of these methods, but
before I do so, is there any particular reason the String was passed and
not the whole Bucket object?

Thanks,

Wido

[0]: https://github.com/wido/cloudstack/commits/ceph-object-store
[1]: https://ceph.io/en/discover/technology/#object
[2]:
https://www.javadoc.io/doc/io.github.twonote/radosgw-admin4j/latest/org/twonote/rgwadmin4j/RgwAdmin.html

 

Re: [VOTE] Adopt Github Discusssions as Users Forum

[Rohit Yadav]

Update - Github Discussions is enabled now for apache/cloudstack repository. 
Some of us have tested to find the Github Dicussions updates are synchronised 
from Github to the users mailing list only (similar to issues and pull 
requests).

You're all welcome to try it here, or start new discussions:
https://github.com/apache/cloudstack/discussions/8343


Regards.


From: Rohit Yadav 
Sent: Monday, December 11, 2023 14:50
To: dev@cloudstack.apache.org ; 
priv...@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: Re: [VOTE] Adopt Github Discusssions as Users Forum

The motion passes with the following votes:

5votes: +1 (binding) - Wei, Bobby, Abhishek, Nicolas, Sven
3 votes: +1 (non-binding) Sina, Suresh, Pearl
1 vote: +0: Daan
2 votes: -0: Lucian, Wido

0 votes: -1 (binding & non-binding)


I'll work with ASF-infra to get the feature enabled in Github and let's start 
to try this.


If for any reasons it doesn't work out, we'll also have an option to get it 
removed. I encourage all PMCs and community at large to exchange feedback on 
this (on our mailing lists). Thank you all for your participation and voting.


Regards.


From: Pearl d'Silva 
Sent: Friday, December 8, 2023 22:21
To: dev@cloudstack.apache.org ; 
priv...@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: Re: [VOTE] Adopt Github Discusssions as Users Forum

+1

Regards,
Pearl Dsilva


From: Rohit Yadav 
Sent: December 4, 2023 3:01 AM
To: dev@cloudstack.apache.org ; 
priv...@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: [VOTE] Adopt Github Discusssions as Users Forum

All,

Following the discussion thread on adopting Github Discussions as users forum 
[1], I put the following proposal for a vote:


  1.  Adopt and use Github Discussions as user forums.
  2.  The Github Discussions feature is tied with the 
us...@cloudstack.apache.org mailing list (PR: 
https://github.com/apache/cloudstack/pull/8274).
  3.  Any project governance and decision-making thread such as voting, 
releases etc. should continue to use the project mailing lists.

Vote will be open for 120 hours (by Friday, 8th Dec).

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)

[1] https://lists.apache.org/thread/hs0295hw9rnmhoh9l2qo5hc4b62hhvk8


Regards.










 

Re: [VOTE] Adopt Github Discusssions as Users Forum

[Rohit Yadav]

The motion passes with the following votes:

5votes: +1 (binding) - Wei, Bobby, Abhishek, Nicolas, Sven
3 votes: +1 (non-binding) Sina, Suresh, Pearl
1 vote: +0: Daan
2 votes: -0: Lucian, Wido

0 votes: -1 (binding & non-binding)


I'll work with ASF-infra to get the feature enabled in Github and let's start 
to try this.


If for any reasons it doesn't work out, we'll also have an option to get it 
removed. I encourage all PMCs and community at large to exchange feedback on 
this (on our mailing lists). Thank you all for your participation and voting.


Regards.


From: Pearl d'Silva 
Sent: Friday, December 8, 2023 22:21
To: dev@cloudstack.apache.org ; 
priv...@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: Re: [VOTE] Adopt Github Discusssions as Users Forum

+1

Regards,
Pearl Dsilva


From: Rohit Yadav 
Sent: December 4, 2023 3:01 AM
To: dev@cloudstack.apache.org ; 
priv...@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: [VOTE] Adopt Github Discusssions as Users Forum

All,

Following the discussion thread on adopting Github Discussions as users forum 
[1], I put the following proposal for a vote:


  1.  Adopt and use Github Discussions as user forums.
  2.  The Github Discussions feature is tied with the 
us...@cloudstack.apache.org mailing list (PR: 
https://github.com/apache/cloudstack/pull/8274).
  3.  Any project governance and decision-making thread such as voting, 
releases etc. should continue to use the project mailing lists.

Vote will be open for 120 hours (by Friday, 8th Dec).

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)

[1] https://lists.apache.org/thread/hs0295hw9rnmhoh9l2qo5hc4b62hhvk8


Regards.







 

Re: [PROPOSE] ACS 4.18.2.0

[Rohit Yadav]

+1

Given, 4.18 branch is benefitting from maintenance work already, I wouldn't 
mind if you want to push it earlier to even say end of Jan, and target release 
in Feb 2024.


Regards.


From: João Jandre Paraquetti 
Sent: Friday, December 8, 2023 23:32
To: dev@cloudstack.apache.org 
Subject: [PROPOSE] ACS 4.18.2.0

Hi all,

As suggested on the 4.20.0.0 discussion thread (see
https://lists.apache.org/thread/nyoddmwydz2t59hsfs7gf0vozlf7n434), I'd
like to propose the release of version 4.18.2.0 with myself as the RM,
here's a rough timeline:

  - From now till the second week of February (2 months): accept bug
fixes and minor improvements
  - Third week of February: accept only blocker and critical bug fixes,
aiming to stabilize the branch.
  - End of February: start cutting RCs, vote and finish release work.

We currently have 7 open PRs [1] and 51 open issues [2] with 4.18.2.0 as
milestone, I believe the above timeline should give enough time to solve
all concerns. In case anyone wants to include a bug fix or a pull
request in 4.18.2.0 milestone, please mention me (JoaoJandre) on github.

If anyone has any suggestions, please voice them.

[1]:
https://github.com/apache/cloudstack/pulls?q=is%3Apr+milestone%3A4.18.2.0+is%3Aopen
[2]:
https://github.com/apache/cloudstack/issues?q=is%3Aopen+is%3Aissue+milestone%3A4.18.2.0

Best regards,
João Jandre


 

Re: 4.20 plans

[Rohit Yadav]

Hi João,

Glad to hear about your interests and I will fully support your effort to 
release manage the next major release 4.20.

In fact you can also help us with 4.18.2.0 maintenance release which will be 
relatively low-effort release and in doing so you can learn the logistics of 
release management and access to Github and CI/CD (including BO), learning how 
to update websites (project and docs) and pre/post release work on a low-effort 
basis.

I like your proposed timeline, for 4.20, free by end of May, would allow 4-5 
months of development work. And I think that would be beneficial for the 
community to have two major releases in a year, with 4.20 release in end ~H1 
'24, possibly a 4.21 in end ~H2 '24.

I've jotted my notes on becoming a release manager here, that could help you:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/%5BDRAFT%5D+How+to+Become+a+CloudStack+Release+Manager
 (I welcome any/all PMCs to review this)


Recently, I had also written my thoughts on growing in the community generally: 
(again, PMCs are welcome to review this - for now these are just my thoughts)

https://cwiki.apache.org/confluence/display/CLOUDSTACK/%5BDRAFT%5D+How+to+Become+a+Committer

https://cwiki.apache.org/confluence/display/CLOUDSTACK/%5BDRAFT%5D+How+to+Become+a+PMC+Member


Regards.


From: João Jandre Paraquetti 
Sent: Wednesday, December 6, 2023 17:57
To: dev@cloudstack.apache.org 
Subject: Re: 4.20 plans

Hello all,

We have quite a few new interesting features prepared for 4.20; there's
the log4j PR, that we plan on merging as soon as 4.19 is released. We
also have a few big PRs to be opened for 4.20:
- Refactoring of the quota UI;
- New feature to allow users to create custom UI themes and apply them
to domains, user accounts, and internet DNS themes that are used to
access the ACS MS;
- Differential volume snapshots/backups for KVM;
- And some more extensions that we are preparing here.

Therefore, I'd like to propose myself as the release manager of
4.20.0.0, if none objects. I'd be guided by Daniel, who has recently
been added to the PMC; any others who are willing to help would be
welcome too. Here's the rough schedule I propose:

- On the third week of May, we freeze the main branch. That means any
feature must be in by the second week of May. Only accept
critical/blocker issues until June.
- As early as possible in June, cut 4.20.0.0 RC1 and further RCs if
necessary, start/conclude vote, and finish release work.

Best regards,
João Jandre

On 12/5/23 13:18, Daan Hoogland wrote:
> devs,
>
> Other than we all have great new plans for integrations and other
> features for 4.20 and we have about 300 issues to solve, There are
> some platform issues that need addressing. So far I can think of
> - the outstanding logging PR
> - java 11 is out of support and we'll need to support a higher version
>
> I think we must address these as soon as we have a release.
> Are there any other issues to address?
>

 

Re: 4.20 plans

[Rohit Yadav]

Wrt regular maintenance work, I think we can discuss the following for next 
year releases (4.20/4.21):


  *   Support python 3.10, including Marvin, VR scripts (**that's still on 
python2 that we must upgrade) and smoketests and other misc scripts
  *   Java 17 or 21 LTS (we'll need to look at which are available in the 
support distros)
  *   New Debian 12 based systemvmtemplate (affects cpvm, ssvm wrt jre and VR 
wrt python3; possibly CKS wrt any changes/new pkgs or deprecation TBD)
  *   Handle EOL support: KVM/EL7, XS7.1, Vmware 6.7... etc. to review
  *   Revisit default test matrix and documentation around tested/supported 
distros and hypervisor
  *   New distros support to review: Ubuntu 24.04, Debian 12


Regards.


From: Daan Hoogland 
Sent: Tuesday, December 5, 2023 21:48
To: dev 
Subject: 4.20 plans

devs,

Other than we all have great new plans for integrations and other
features for 4.20 and we have about 300 issues to solve, There are
some platform issues that need addressing. So far I can think of
- the outstanding logging PR
- java 11 is out of support and we'll need to support a higher version

I think we must address these as soon as we have a release.
Are there any other issues to address?

--
Daan

 

Re: [DISCUSS] Adopting Github Discusssions Users Forum

[Rohit Yadav]

Lucian, all,

Your argument pretty would also apply to also our current use of Github issues 
and pull requests (and milestones, CI/github actions etc), which have become 
are daily drivers.

I had another round of checks - from an ASF/mailing lists point of view, in 
case Github goes the wrong path, all such discussions will still be available 
on users@ ML (archive) and possibly a migration path would be determined by the 
ASF infra (such as to Gitlab etc).


Regards.


From: Nux 
Sent: Tuesday, November 28, 2023 15:40
To: dev@cloudstack.apache.org 
Cc: Rohit Yadav 
Subject: Re: [DISCUSS] Adopting Github Discusssions Users Forum

Personally I'm against that, as it will dilute the community and once
the mailing lists will get inactive they'll stay that way.

Also github/discussions is a proprietary platform at Microsoft's whim, I
think this goes against the spirit of the project as free software.

That said, I'll be "voting" -0, don't want to get in the way of
"progress".

On 2023-11-28 09:28, Rohit Yadav wrote:
> All,
>
> It's been a while since I had last proposed adopting and trying the
> Github Discussions feature for our users community. Since then, the ASF
> infra seems to have enabled integration and allowing Discussions
> integrated with mailing lists:
> https://github.com/search?q=.asf.yaml+discussions=code
>
> Following discussions with both technical and non-technical users from
> the CCC, I believe we should try this out and use it for users to
> discuss their ideas, questions, and problems, all that traditionally
> has happened on the users@ ML; while been integrating such discussions
> on the users@ ML. The Discussions platform could be used by developers
> too to get feedback from users.
>
> That said, we MUST continue to use our mailing lists for any project
> governance related matters such as releases related discussions,
> releases voting, and any form of consensus and decision making.
>
> I've proposed a PR for this here where the discussions feature is tied
> to users@ ML:
> https://github.com/apache/cloudstack/pull/8274/files
>
> Thoughts and feedback?
>
>
> Regards.

 

[VOTE] Adopt Github Discusssions as Users Forum

[Rohit Yadav]

All,

Following the discussion thread on adopting Github Discussions as users forum 
[1], I put the following proposal for a vote:


  1.  Adopt and use Github Discussions as user forums.
  2.  The Github Discussions feature is tied with the 
us...@cloudstack.apache.org mailing list (PR: 
https://github.com/apache/cloudstack/pull/8274).
  3.  Any project governance and decision-making thread such as voting, 
releases etc. should continue to use the project mailing lists.

Vote will be open for 120 hours (by Friday, 8th Dec).

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)

[1] https://lists.apache.org/thread/hs0295hw9rnmhoh9l2qo5hc4b62hhvk8


Regards.

 

[DISCUSS] Adopting Github Discusssions Users Forum

[Rohit Yadav]

All,

It's been a while since I had last proposed adopting and trying the Github 
Discussions feature for our users community. Since then, the ASF infra seems to 
have enabled integration and allowing Discussions integrated with mailing 
lists: https://github.com/search?q=.asf.yaml+discussions=code

Following discussions with both technical and non-technical users from the CCC, 
I believe we should try this out and use it for users to discuss their ideas, 
questions, and problems, all that traditionally has happened on the users@ ML; 
while been integrating such discussions on the users@ ML. The Discussions 
platform could be used by developers too to get feedback from users.

That said, we MUST continue to use our mailing lists for any project governance 
related matters such as releases related discussions, releases voting, and any 
form of consensus and decision making.

I've proposed a PR for this here where the discussions feature is tied to 
users@ ML:
https://github.com/apache/cloudstack/pull/8274/files

Thoughts and feedback?


Regards.

 

Re: new PMC member: Abhishek Kumar

[Rohit Yadav]

Congratulations Abhishek, well deserved!


Regards.


From: Daman Arora 
Sent: Thursday, November 23, 2023 17:46
To: dev@cloudstack.apache.org 
Cc: users 
Subject: Re: new PMC member: Abhishek Kumar

Many congrats Abhishek!

On Thu, Nov 23, 2023, 9:25 p.m. Wei ZHOU  wrote:

> Congratulations Abhishek!
>
>
>
> 在 2023年11月23日星期四，Daan Hoogland  写道：
>
> > The Project Management Committee (PMC) for Apache CloudStack
> > has invited Abhishek Kumar to become a PMC member and we are pleased
> > to announce that they have accepted.
> >
> > Abhishek has contributed in the past and has shown effort to make the
> > project run smoothly. He is also the Release Manager for the upcoming
> > 4.19 release.
> >
> > please join me in congratulating Abhishek
> >
> > --
> > Daan
> >
>

 

Re: [DISCUSS] New benchmarking tool

[Rohit Yadav]

Thanks all, since there have been no objections I've got a new repository 
created here:

https://github.com/apache/cloudstack-csbench


Regards.


From: Daan Hoogland 
Sent: Thursday, November 2, 2023 15:13
To: dev@cloudstack.apache.org 
Cc: Rohit Yadav 
Subject: Re: [DISCUSS] New benchmarking tool

thanks Rohit,
It is a great idea. I have some questions concerning "measuring is influencing" 
and "prerequisites",
but those should not stop us from creating a repo for this in the project
great idea,

On Thu, Nov 2, 2023 at 9:58 AM Nux mailto:n...@li.nux.ro>> 
wrote:
Great idea, looking forward to it.


On 2023-11-01 16:34, Rohit Yadav wrote:
> All,
>
> I want to kickstart a discussion of developing a new tool - csbench,
> that can help with generating resource load and measuring  the
> performance and efficiency of Apache CloudStack APIs.
>
> Much like cmk, this tool can be written in Go and can be useful for
> anybody to benchmark CloudStack API performance. It's still in a
> nascent stage and can benefit from feedback and input from the wider
> community early in the development process.
>
> If there are no objections, I propose to create a cloudstack-csbench
> repo in which this tool can be developed. Thoughts and feedback?
> Thanks.
>
>
> Regards.


--
Daan

 

Re: Can't upload ova file format

[Rohit Yadav]

Hi,

OVA templates aren't supported for KVM. You could convert the ova/vmdk to 
qcow2/img to be able to use it with KVM.


Regards.


From: Technology Rss 
Sent: Sunday, November 5, 2023 11:25
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Subject: Can't upload ova file format

*Hi,*

My ACS version is 4.18.1.0, kvm Hypervisor, I try to upload ova format
template but I face below error.

https://prnt.sc/HeGZoHq-SQ-b

I see ova file is supported.

What can I do now? Please help me...

--

*Thanks & Regards.*

*Support Admin*



*Facebook  | Twitter
 | YouTube
 | LinkedIn
*

*Address : *116/1 West Malibagh, D. I. T Road

Dhaka-1217, Bangladesh

*Mob :* +88 01716915504

*Email :* support.ad...@technologyrss.com

*Web :* www.technologyrss.com

 

[DISCUSS] New benchmarking tool

[Rohit Yadav]

All,

I want to kickstart a discussion of developing a new tool - csbench, that can 
help with generating resource load and measuring  the performance and 
efficiency of Apache CloudStack APIs.

Much like cmk, this tool can be written in Go and can be useful for anybody to 
benchmark CloudStack API performance. It's still in a nascent stage and can 
benefit from feedback and input from the wider community early in the 
development process.

If there are no objections, I propose to create a cloudstack-csbench repo in 
which this tool can be developed. Thoughts and feedback? Thanks.


Regards.

 

Re: [DISCUSS] Upgrading Mockito & phasing out powermock

[Rohit Yadav]

Good work Vishesh!


Regards.


From: Nicolas Vazquez 
Sent: Tuesday, September 26, 2023 20:23
To: dev@cloudstack.apache.org 
Subject: Re: [DISCUSS] Upgrading Mockito & phasing out powermock

Great work Vishesh, thanks!

Regards,
Nicolas Vazquez


From: Daan Hoogland 
Date: Tuesday, 26 September 2023 at 11:15
To: dev@cloudstack.apache.org 
Subject: Re: [DISCUSS] Upgrading Mockito & phasing out powermock
great, thanks you for your persistence and effort in general.

On Tue, Sep 26, 2023 at 1:51 PM Vishesh Jindal 
wrote:

> Hi all,
>
> I wanted to update everyone that powermock is completely removed from main
> branch now. Thank you everyone for helping out on this.
>
> Regards,
> Vishesh
>
> 
> From: Kishan Kavala 
> Sent: Friday, June 9, 2023 1:30 PM
> To: dev@cloudstack.apache.org 
> Subject: RE: [DISCUSS] Upgrading Mockito & phasing out powermock
>
> +1
> Agree with the approach, Vishesh.
>
>
>
>
>
>
>
> -Original Message-
> From: Wei ZHOU 
> Sent: Tuesday, June 6, 2023 8:11 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Upgrading Mockito & phasing out powermock
>
> lgtm. go ahead Vishesh.
>
> -Wei
>
>
> On Tue, 6 Jun 2023 at 14:17, Vishesh Jindal 
> wrote:
>
> > Hi all,
> >
> > I am working on upgrading Mockito's version & phasing out powermock.
> > For new maven modules, I would request all to use Mockito's mockStatic
> > instead of Powermock.
> >
> > Why?
> > Powermock's last release was on Nov 2, 2020. The project seems to have
> > been abandoned. Powermock has compatibility issues with Mockito's
> > latest version as well.
> >
> > How?
> > The only usage for PowerMock I could see in code was for mocking
> > static methods. Since Mockito v3.4.0, it has the capability to mock
> static methods.
> > I plan to migrate tests to Mockito's mockStatic instead of PowerMock.
> > This will have to be done module by module and will take some time.
> >
> > I have prepared a PR here:
> > https://github.com/apache/cloudstack/pull/7577
> >
> > This PR upgrades mockito from v3.2.4 to v3.12.4 and removes the usage
> > of PowerMock from utils module.
> >
> >
> > Let me know if you have any questions/concerns.
> >
> > Regards,
> > Vishesh
> >
> >
> >
> >
> >
>


--
Daan




 

Re: [ANNOUNCEMENT] Apache CloudStack LTS Maintenance Release 4.18.1.0

[Rohit Yadav]

Congratulations everyone on the new release, and thanks Wei and everyone 
involved in the release and voting process.


Regards.


From: Nicolas Vazquez 
Sent: Friday, September 15, 2023 20:36
To: us...@cloudstack.apache.org 
Cc: Wei ZHOU 
Subject: Re: [ANNOUNCEMENT] Apache CloudStack LTS Maintenance Release 4.18.1.0

Great, thanks Wei!

Regards,
Nicolas Vazquez


On 15/9/23, 11:18, "Sina Kashipazha"  
wrote:

Congrats! Well done Wei!



--



 

- Original Message ---
On Friday, September 15th, 2023 at 3:56 PM, Nux 
mailto:n...@li.nux.ro>> wrote:


>

>

> That's amazing! Thanks, Wei!
>

>

>

> On 2023-09-15 14:44, Wei ZHOU wrote:
>

> > The Apache CloudStack project is pleased to announce the release of
> > CloudStack 4.18.1.0.
> >

> > The CloudStack 4.18.1.0 release is a maintenance release as part of
> > its 4.18.x LTS branch and contains around 200 fixes and
> > improvements since the CloudStack 4.18.0.0 release. Some of the
> > highlights include:
> >

> > - Support Managed User Data in AutoScale VM groups
> > - Support CKS (CloudStack Kubernetes Cluster) in VPC tiers
> > - Support for VMware 8.0.0.x
> > - Several Hypervisor (VMware, KVM, XenServer) fixes and improvements
> > - Several UI fixes and improvements
> > - Several Network (L2, VXLAN, etc) fixes and improvements
> > - Several System VM (CPVM, SSVM) fixes and improvements
> > - Improve Solidfire storage plugin integration on VMware
> > - Support volume migration in ScaleIO/PowerFlex within and across
> > ScaleIO/PowerFlex storage clusters
> > - Volume encryption support for StorPool
> > - Fix CloudStack upgrade with some MySQL versions
> > - Fix guest OSes and guest OS mappings in CloudStack database
> >

> > CloudStack LTS branches are supported for 18 months and will receive
> > updates for the first 12 months and only security updates in the last
> > 6 months.
> >

> > Apache CloudStack is an integrated Infrastructure-as-a-Service (IaaS)
> > software platform that allows users to build feature-rich public and
> > private cloud environments. CloudStack includes an intuitive user
> > interface and rich API for managing the compute, networking, software,
> > and storage resources. The project became an Apache top-level project
> > in March, 2013.
> >

> > More information about Apache CloudStack can be found at:
> > https://cloudstack.apache.org/
> >

> > # Documentation
> >

> > What's new in CloudStack 4.18.1.0:
> > https://docs.cloudstack.apache.org/en/4.18.1.0/releasenotes/about.html
> >

> > The 4.18.1.0 release notes include a full list of issues fixed, as
> > well as upgrade instructions from previous versions of Apache
> > CloudStack, and can be found at:
> > https://docs.cloudstack.apache.org/en/4.18.1.0/releasenotes/
> >

> > The official installation, administration, and API documentation for
> > each of the releases are available on our documentation page:
> > https://docs.cloudstack.apache.org/
> >

> > # Downloads
> >

> > The official source code for the 4.18.1.0 release can be downloaded
> > from our downloads page:
> > https://cloudstack.apache.org/downloads.html
> >

> > In addition to the official source code release, individual
> > contributors have also made convenience binaries available on the
> > Apache CloudStack download page, and can be found at:
> >

> > https://download.cloudstack.org/el/7/
> > https://download.cloudstack.org/el/8/
> > https://download.cloudstack.org/ubuntu/dists/
> > https://www.shapeblue.com/packages/

Re: GSOC 2023 Results

[Rohit Yadav]

Well done Ayush, thank you for your contribution! Looking forward to still 
seeing you around in the community even after the GSoC.


Regards.


From: Nicolas Vazquez 
Sent: Tuesday, September 12, 2023 19:40
To: users ; dev@cloudstack.apache.org 
; pandey@gmail.com 
Subject: GSOC 2023 Results

Hi all,

I’m happy to share with the community that our participation at the Google 
Summer of Code 2023 is finished with one successful project [1].

Please join me congratulating Ayush for his great work on extending the 
Import/Export Instances functionality to KVM [2]. Looking forward to seeing you 
around in the community!

[1] https://summerofcode.withgoogle.com/programs/2023/projects/f0gpheQM
[2] https://github.com/apache/cloudstack/pull/7712

Regards,
Nicolas Vazquez





 

Re: [VOTE][RESULT] Apache CloudStack 4.18.1.0 (RC3)

[Rohit Yadav]

Thanks Wei, and congratulations everyone!


Regards.


From: Wei ZHOU 
Sent: Tuesday, September 12, 2023 14:35
To: dev@cloudstack.apache.org ; users 

Subject: [VOTE][RESULT] Apache CloudStack 4.18.1.0 (RC3)

Hi all,

After more than 72hrs the vote for CloudStack 4.18.1.0 *passes* with
5 PMC + 1 non-PMC votes.

+1 (PMC / binding)
Rohit Yadav
Nux (Lucian)
Boris Stoyanov
Nicolas Vazquez
Wei Zhou

+1 (non binding)
Harikrishna Patnala

0
none

-1
none

Thanks to everyone participating.

I will now prepare the release announcement to go out after 24 hours to
give the mirrors time to catch up.

-Wei



 

On Thu, 7 Sept 2023 at 10:34, Wei ZHOU  wrote:

> Hi all,
>
> I've created a 4.18.1.0-RC3, with the following artifacts up for a vote:
>
> Git Branch and Commit SH:
> https://github.com/apache/cloudstack/commits/4.18.1.0-RC20230907T0850
> Commit: 4bdff06acd3630180f85ffe2f54add972607bbb4
>
> Source release (checksums and signatures are available at the following
> location):https://dist.apache.org/repos/dist/dev/cloudstack/4.18.1.0/
>
> PGP release keys (signed using 1503DFE7C8226103):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> Vote will be open for 72 hours.
>
> 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)
>

Re: [VOTE] Apache CloudStack 4.18.1.0 (RC3)

[Rohit Yadav]

+1 binding, have manually tested the new changes since RC2 in an adv zone KVM 
env with nfs and local storage.

Regards.

Regards.

From: Wei ZHOU 
Sent: Thursday, September 7, 2023 2:05:26 PM
To: dev@cloudstack.apache.org ; users 

Subject: Re: [VOTE] Apache CloudStack 4.18.1.0 (RC3)

Hi all,

You can find the (unofficial) packages at
http://download.cloudstack.org/testing/4.18.1.0-RC20230907T0850/ for your
convenience.

Kind regards
Wei





 

On Thu, 7 Sept 2023 at 10:34, Wei ZHOU  wrote:

> Hi all,
>
> I've created a 4.18.1.0-RC3, with the following artifacts up for a vote:
>
> Git Branch and Commit SH:
> https://github.com/apache/cloudstack/commits/4.18.1.0-RC20230907T0850
> Commit: 4bdff06acd3630180f85ffe2f54add972607bbb4
>
> Source release (checksums and signatures are available at the following
> location):https://dist.apache.org/repos/dist/dev/cloudstack/4.18.1.0/
>
> PGP release keys (signed using 1503DFE7C8226103):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> Vote will be open for 72 hours.
>
> 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)
>

Re: [VOTE] Apache CloudStack 4.18.1.0 (RC2)

[Rohit Yadav]

Thanks Wei.



Regards.


From: Wei ZHOU 
Sent: Wednesday, September 6, 2023 13:49
To: dev@cloudstack.apache.org ; users 

Subject: Re: [VOTE] Apache CloudStack 4.18.1.0 (RC2)

Hi all,

Thanks a lot for your testing, Rohit, Hari, Lucian, Nicolas and Bobby.

Unfortunately Rohit found a critical issue that live migration failed
between kvm hosts with local storage pools:
https://github.com/apache/cloudstack/issues/7942
We have proposed a fix: https://github.com/apache/cloudstack/pull/7945

I will create RC3 when the fix is verified and merged. The issue impacts
kvm hosts with local storage only.

-Wei



 

On Fri, 1 Sept 2023 at 09:39, Wei ZHOU  wrote:

> Hi all,
>
> I've created a 4.18.1.0-RC2, with the following artifacts up for a vote:
>
> Git Branch and Commit SH:
> https://github.com/apache/cloudstack/commits/4.18.1.0-RC20230901T0817
> Commit: 0e7f7d42f0ec68a360fafa7de21ea06577ed032c
>
> Source release (checksums and signatures are available at the following
> location):https://dist.apache.org/repos/dist/dev/cloudstack/4.18.1.0/
>
> PGP release keys (signed using 1503DFE7C8226103):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> Vote will be open for 72 hours.
>
> 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)
>

Re: [VOTE] Apache CloudStack 4.18.1.0 (RC2)

[Rohit Yadav]

Wei pointed out privately to me that it's already in our docs at 
https://docs.cloudstack.apache.org/en/latest/upgrading/upgrade/upgrade-4.17.html#database-preparation

My bad, I didn't notice it earlier :)


Regards.


From: Nux 
Sent: Monday, September 4, 2023 19:44
To: dev@cloudstack.apache.org 
Cc: users 
Subject: Re: [VOTE] Apache CloudStack 4.18.1.0 (RC2)

Cheers Rohit,

I'm for including the routines bit in the release or upgrade notes. We
haven't had such a gotcha until now, even though it's not strictly
within scope.

Regards

On 2023-09-04 14:03, Rohit Yadav wrote:
> +1 (binding)
>
> Upgraded a multi-zone (edge and core) KVM env with NFS, local storage
> and Linstor storage from 4.18.0.0 to 4.18.1.0. Post upgrade tested VM
> deployment as root admin and normal user account.
>
> I hit the issue of procedures not found as I had moved my DB from one
> host to another and didn't export the routines using mysqldump -R flag.
> I could apply them manually courtesy of Wei. I think we should document
> this that people moving their DBs must also backup/dump the routines
> (procedures), though I don't think that's a usual thing that users
> would normally do - and is outside of scope of CloudStack.
>
>
>
> Regards.
>
> 
> From: Wei ZHOU 
> Sent: Friday, September 1, 2023 13:09
> To: dev@cloudstack.apache.org ; users
> 
> Subject: [VOTE] Apache CloudStack 4.18.1.0 (RC2)
>
> Hi all,
>
> I've created a 4.18.1.0-RC2, with the following artifacts up for a
> vote:
>
> Git Branch and Commit SH:
> https://github.com/apache/cloudstack/commits/4.18.1.0-RC20230901T0817
> Commit: 0e7f7d42f0ec68a360fafa7de21ea06577ed032c
>
> Source release (checksums and signatures are available at the following
> location):https://dist.apache.org/repos/dist/dev/cloudstack/4.18.1.0/
>
> PGP release keys (signed using 1503DFE7C8226103):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> Vote will be open for 72 hours.
>
> 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)

 

Re: [VOTE] Apache CloudStack 4.18.1.0 (RC2)

[Rohit Yadav]

+1 (binding)

Upgraded a multi-zone (edge and core) KVM env with NFS, local storage and 
Linstor storage from 4.18.0.0 to 4.18.1.0. Post upgrade tested VM deployment as 
root admin and normal user account.

I hit the issue of procedures not found as I had moved my DB from one host to 
another and didn't export the routines using mysqldump -R flag. I could apply 
them manually courtesy of Wei. I think we should document this that people 
moving their DBs must also backup/dump the routines (procedures), though I 
don't think that's a usual thing that users would normally do - and is outside 
of scope of CloudStack.



Regards.


From: Wei ZHOU 
Sent: Friday, September 1, 2023 13:09
To: dev@cloudstack.apache.org ; users 

Subject: [VOTE] Apache CloudStack 4.18.1.0 (RC2)

Hi all,

I've created a 4.18.1.0-RC2, with the following artifacts up for a vote:

Git Branch and Commit SH:
https://github.com/apache/cloudstack/commits/4.18.1.0-RC20230901T0817
Commit: 0e7f7d42f0ec68a360fafa7de21ea06577ed032c

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

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

Vote will be open for 72 hours.

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)

 

Re: Reminder on triaging role to access and use Github better

[Rohit Yadav]

Hi Daan,

Sorry missed this email - yes we can put this somewhere on the project 
wiki/website if required or on Github's README.


Regards.


From: Daan Hoogland 
Sent: Friday, July 14, 2023 12:05
To: dev@cloudstack.apache.org ; Rohit Yadav 

Cc: us...@cloudstack.apache.org 
Subject: Re: Reminder on triaging role to access and use Github better

@Rohit Yadav  is this worth mentioning on the website
somewhere?

On Tue, May 9, 2023 at 8:33 PM Rohit Yadav 
wrote:

> All,
>
> Reminder - we've ability to add frequent contributors and add them as
> collaborators [1] to our Github repos. This allows them to use project
> Github with ability to report issue with tags, and be assigned to issues
> and PRs. This is done via project repo specific .asf.yaml file.
>
> If you're a frequent contributor(s) and want to be able to add tags and be
> assigned on issues and PRs, you may share your github users ID or raise a
> Github issue. Thanks.
>
> [1]
> https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-AssigningexternalcollaboratorswiththetriageroleonGitHub
>
>
> Regards.
>
>
>
>

--
Daan

 

Re: [DISCUSS] New Design for the Apache CloudStack Website

[Rohit Yadav]

Thanks Ivet, the new iterated design looks impressive especially some of the 
new graphical elements.

+1 to moving forward with the proposed design. Let's collect any further 
feedback and ideas from the community and if there are no objections go ahead 
with updating the preview/staging site (https://cloudstack.staged.apache.org/) 
and eventually publishing the website.

Just to be clear on the CMS integration - the ASF infra has declined supporting 
a 3rd party git-based CMS that can be used with the project website. This is 
such a shame as I had created PoCs with some rather okay-ist git-based CMS such 
as Netlify-CMS, TinaCMS and SpinalCMS which would give similar UI-based 
workflow like the old Roller-based blog did.

Nevertheless, for the purposes of publishing blogs the new Github-based 
document/markdown editor/CMS is fair enough and now allows uploading of assets 
(images, files etc.) and blog that can be edited directly for any committer 
incl. PMC members logged into Github and upon saving such changes the website 
is published by an automatic Github action that builds and published the 
websites. Unfortunately, any non-committer would need to follow the PR 
workflow. I had this documented at 
https://cloudstack.staged.apache.org/website-guide/ that I can help further 
update in this regard.


Regards.


From: Ivet Petrova 
Sent: Wednesday, August 30, 2023 19:04
To: Giles Sirett 
Cc: dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org ; Marketing 

Subject: Re: [DISCUSS] New Design for the Apache CloudStack Website

Hi All,

I uploaded the design here: 
https://drive.google.com/file/d/1pef7xWWMPYAA5UkbS_XMUxrz53KB7J5t/view?usp=sharing


Kind regards,





 

On 30 Aug 2023, at 16:31, Giles Sirett 
mailto:giles.sir...@shapeblue.com>> wrote:

Hi Ivet – thanks for pushing forward with this – excited to review a new design.

On that note, I cant see a link in your mail ☹

Kind Regards
Giles


Giles Sirett
CEO
giles.sir...@shapeblue.com
www.shapeblue.com




From: Ivet Petrova 
mailto:ivet.petr...@shapeblue.com>>
Sent: Wednesday, August 30, 2023 10:14 AM
To: us...@cloudstack.apache.org; Marketing 
mailto:market...@shapeblue.com>>
Cc: dev mailto:dev@cloudstack.apache.org>>
Subject: [DISCUSS] New Design for the Apache CloudStack Website

Hello,

I would like to start a discussion on the design of the Apache CloudStack 
Website and to propose a new design for it.

As we all know, the website has not been changed for years in terms of design 
and information. The biggest issue we know we have is that the website is not 
showing the full potential of CloudStack. In addition to it during discussions 
with many community members, I have noted the following issues:
- the existing website design is old-school
- the current homepage does not collect enough information to show CloudStack's 
strengths
- current website design is missing images from the ACS UI and cannot create a 
feel for the product in the users
- the website has issues on a mobile device
- we lack any graphic and diagrams
- some important information like how to download is not very visible

I collected a lot of feedback during last months and want to propose a new up 
to date design for the website, which is attached below. The new design will 
bring:
- improved UX
- look and feel corresponding to the CloudStack's capabilities and strengths
- more graphical elements, diagrams
- better branding
- more important information, easily accessible for the potential users

I hope you will like the new design – all feedback welcome. Once we have the 
design finalised, we will use Rohit’s proposal previously of a CMS, which is 
easy to edit.

[cid:B5517475-02DA-472A-BD1D-F3B600AD28ED]

Kind regards,

Re: [VOTE] Apache Cloudstack 4.18.1.0

[Rohit Yadav]

Thanks Wei.



Regards.


From: Wei ZHOU 
Sent: Thursday, August 31, 2023 14:27
To: dev@cloudstack.apache.org ; users 

Subject: Re: [VOTE] Apache Cloudstack 4.18.1.0

Hi all,

This vote has to be closed, as we found a critical issue that the
direct-download template cannot be registered for KVM.
Please get more information at
https://github.com/apache/cloudstack/issues/7929

-Wei



 

On Tue, 29 Aug 2023 at 09:56, Wei ZHOU  wrote:

> Hi all,
>
> I've created a 4.18.1.0-RC1, with the following artifacts up for a vote:
>
> Git Branch and Commit SH:
> https://github.com/apache/cloudstack/commits/4.18.1.0-RC20230828T2026
> Commit: ff402faff06667e6e819eaee037400ed2005d5d2
>
> Source release (checksums and signatures are available at the following
> location):https://dist.apache.org/repos/dist/dev/cloudstack/4.18.1.0/
>
> PGP release keys (signed using 1503DFE7C8226103):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> Vote will be open for 72 hours.
>
> 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)
>

Re: Unable to add host error ACS

[Rohit Yadav]

Hi again,

You may try to re-add the host and tail the /var/log/cloudstack/agent/* 
(usually there is a setup.log) to watchout for errors.

Is this a test/virtualised environment? You may want to run kvm-ok and ensure 
that /dev/kvm exists and works. It's possible the KVM host doesn't have 
/dev/kvm or missing any packages or libvirt isn't setup properly.


Regards.


From: Wei ZHOU 
Sent: Monday, August 28, 2023 12:31
To: dev@cloudstack.apache.org 
Subject: Re: Unable to add host error ACS

Hi,

If libvirtd does not work, please fix it before adding the host to
cloudstack.

You can check the output of `systemctl status libvirtd` or `journalctl -xeu
libvirtd`


-Wei

On Mon, 28 Aug 2023 at 08:56, Technology Mail 
wrote:

> Thank you so much!,
> I followed your mansion step but error is same, Please see my MGMT
> server error like below:
>
>

 

Re: Unable to add host error ACS

[Rohit Yadav]

Hi,

It appears there's something wrong in your 
/etc/cloudstack/agent/agent.properties, it can't find the passphrase to use 
cloud.jks as per:

2023-03-27 18:17:45,259 INFO  [kvm.resource.LibvirtComputingResource] 
(main:null) (logid:) Failed to find passphrase for keystore: cloud.jks

You may re-add the host, or try this workaround:


  1.  backup and then delete the cloud.* files from /etc/cloudstack/agent/ 
directory
  2.  change auth strictness global setting to false 
(ca.plugin.root.auth.strictness) in cloudstack temporarily
  3.  restart cloudstack agent on the KVM host, and once it's connected, in 
CloudStack go to the UI-> infra ->host -> select the specific host -> click 
button to re-provision certficates (this will resetup the cloud.jks and 
certificates on the kvm host)
  4.  finally, reset the ca.plugin.root.auth.strictness back to true


Regards.


From: Technology Mail 
Sent: Sunday, August 27, 2023 13:33
To: Rohit Yadav ; us...@cloudstack.apache.org 
; dev@cloudstack.apache.org 

Subject: Re: Unable to add host error ACS


Now I am using 4.18, Ubuntu 20.04 server. KVM server cloud and libvirt agent 
service not start.

see error below:

Error:

++

root@kvm:~# tail -f /var/log/cloudstack/agent/agent.log
2023-03-27 18:17:43,962 INFO  [cloud.agent.AgentShell] (main:null) (logid:) 
Implementation Version is 4.18.0.0
2023-03-27 18:17:43,979 INFO  [cloud.agent.AgentShell] (main:null) (logid:) 
agent.properties found at /etc/cloudstack/agent/agent.properties
2023-03-27 18:17:44,210 INFO  [cloud.agent.AgentShell] (main:null) (logid:) 
Defaulting to using properties file for storage
2023-03-27 18:17:44,223 INFO  [cloud.agent.AgentShell] (main:null) (logid:) 
Defaulting to the constant time backoff algorithm
2023-03-27 18:17:44,440 INFO  [cloud.utils.LogUtils] (main:null) (logid:) log4j 
configuration found at /etc/cloudstack/agent/log4j-cloud.xml
2023-03-27 18:17:44,441 INFO  [cloud.agent.AgentShell] (main:null) (logid:) 
Using default Java settings for IPv6 preference for agent connection
2023-03-27 18:17:44,951 INFO  [cloud.agent.Agent] (main:null) (logid:) id is
2023-03-27 18:17:45,018 ERROR [kvm.resource.LibvirtComputingResource] 
(main:null) (logid:) uefi properties file not found due to: Unable to find file 
uefi.properties.
2023-03-27 18:17:45,259 INFO  [kvm.resource.LibvirtComputingResource] 
(main:null) (logid:) Failed to find passphrase for keystore: cloud.jks
2023-03-27 18:17:45,280 INFO  [kvm.resource.LibvirtConnection] (main:null) 
(logid:) No existing libvirtd connection found. Opening a new one
+


Thanks.


On 6/27/2021 6:45 PM, Rohit Yadav wrote:
Thanks for sharing, glad the issue is resolved. The specific issue only affects 
4.15.0.0 and older releases, this issue is however fixed in 4.15.1.0.

After adding hosts you may actually revert the original sshd configuration.


Regards.






From: Technologyrss Mail 
<mailto:technologyrss.m...@gmail.com>
Sent: Sunday, June 27, 2021 13:03
To: Wei ZHOU <mailto:ustcweiz...@gmail.com>; 
dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org> 
<mailto:dev@cloudstack.apache.org>
Subject: Re: Unable to add host error ACS


Thank you so much!
This 3 lines add into sshd_config file and restart sshd service then solved!

PubkeyAcceptedKeyTypes=+ssh-dss
HostKeyAlgorithms=+ssh-dss
KexAlgorithms=+diffie-hellman-group1-sha1

I am always try to find out ACS properly working with latest OS with latest 
version. I have Tech blog with YouTube channel.
Always I am appropriate your help & working as previous.

---
Alamin

On 6/27/2021 1:15 PM, Wei ZHOU wrote:
Hi,

Have you tried with 
http://docs.cloudstack.apache.org/en/4.15.0.0/releasenotes/about.html#workaround-for-adding-newer-kvm-hosts
 ?

-Wei


 

On Sun, 27 Jun 2021 at 02:18, Technologyrss Mail 
mailto:technologyrss.m...@gmail.com>> wrote:

>From MGMT error log

[cid:part3.64E24953.345219EA@gmail.com]

>From KVM error log

[cid:part4.5B07A141.1406078A@gmail.com]

---Alamin

On 6/27/2021 12:24 AM, Wei ZHOU wrote:

Are you able to ssh into host using username/password ?

-Wei

On Sat, 26 Jun 2021 at 20:02, Technologyrss Mail <
technologyrss.m...@gmail.com<mailto:technologyrss.m...@gmail.com>> wrote:



Please see below error, This is from ACS MGMT log error.

2021-06-25 18:29:23,782 WARN [c.c.a.d.ParamGenericValidationWorker]
(qtp1644231115-18:ctx-ad53a30c ctx-da493b27) (logid:fc697fe9) Received
unknown parameters for command addHost. Unknown parameters : clustertype
2021-06-25 18:29:23,812 INFO  [c.c.r.ResourceManagerImpl]
(qtp1644231115-18:ctx-ad53a30c ctx-da493b27) (logid:fc697fe9) Trying to
add a new host at http://10.66.100.50 in data center 1
2021-06-25 18:29:24,034 WARN  [c.c.h.k.d.LibvirtServerDiscoverer]
(qtp1644231115-18:ctx-ad53a30c ctx-da493b27) (logid:fc697fe9) can't
setup agent, due to java.io.IOExcepti

Re: new PMC member: Daniel Salvador

[Rohit Yadav]

Congratulations and welcome Daniel!


Regards.


From: Ruben Bosch 
Sent: Friday, August 25, 2023 16:26
To: dev@cloudstack.apache.org 
Subject: Re: new PMC member: Daniel Salvador

Welcome, Daniel!

Met vriendelijke groet / Kind regards,

Ruben Bosch
CLDIN


 

> On 25 Aug 2023, at 12:55, Daan Hoogland  wrote:
>
> The Project Management Committee (PMC) for Apache [PROJECT]
> has invited Daniel Salvador to become a PMC member and we are pleased
> to announce that they have accepted.
>
> Daniel has contributed in the past and has shown effort to make the
> project run smoothly
>
> please join me in congratulating Daniel

Re: new committer: Sina Kashipazha

[Rohit Yadav]

Congratulations and welcome Sina!



Regards.


From: Ruben Bosch 
Sent: Friday, August 25, 2023 16:24
To: dev@cloudstack.apache.org 
Subject: Re: new committer: Sina Kashipazha

Welcome Sina!

Met vriendelijke groet / Kind regards,

Ruben Bosch
CLDIN


 

> On 25 Aug 2023, at 12:53, Daan Hoogland  wrote:
>
> The Project Management Committee (PMC) for Apache [PROJECT]
>
> has invited Sina Kashipazha to become a committer and we are pleased
> to announce that they have accepted.
>
> Sina has been active as a contributor in several ways; code, testing,
> talks, documentation
>
> Please join me in welcoming Sina

Re: new committer: John Bampton

[Rohit Yadav]

Congratulations and welcome John!


Regards.


From: Ruben Bosch 
Sent: Friday, August 25, 2023 16:22
To: dev@cloudstack.apache.org 
Subject: Re: new committer: John Bampton

Welcome John!

Met vriendelijke groet / Kind regards,

Ruben Bosch
CLDIN


 

> On 25 Aug 2023, at 12:51, Daan Hoogland  wrote:
>
> The Project Management Committee (PMC) for Apache CloudStack
> has invited Jown Bampton to become a committer and we are pleased
> to announce that they have accepted.
>
> John is mostly active on CI and build specific issues.
>
>
> please join me in welcoming John to the project
>
> --
> Daan

Re: [Consultation] Remove DB HA feature (db.ha.enabled)

[Rohit Yadav]

nently mentioned anywhere new
>>> adopters may go ahead with that on production. So I guess best to
>>> remove or at least mention that it is not production grade.
>>>
>>> Thanks
>>> Shiv
>>>
>>>
 

> On 22-Aug-2023, at 20:12, Nux  wrote:
>>>>
>>>> But what do you think of the removal of DB HA code?
>>>>
>>>> When using Galera you need to query against a single node, don't
>>>> spread the load among all 3, as this will break certain locking
>>>> functionality in Cloudstack and lead to problems.
>>>>
>>>> In a Haproxy configuration you should be keeping just one active, eg:
>>>> server galera1 10.0.3.2:3306 check
>>>> server galera2 10.0.3.3:3306 check backup
>>>> server galera3 10.0.3.4:3306 check backup
>>>>
>>>> Regards
>>>>
>>>> On 2023-08-22 15:36, K B Shiv Kumar wrote:
>>>>> We faced some issues when running Galera. We went back to master
>>>>> slave.
>>>>> Anyone using Galera in production for a long time?
>>>>> Regards,
>>>>> Shiv
>>>>>> On 22-Aug-2023, at 19:34, Nux  wrote:
>>>>>> Happy to contribute a doc on how to achieve HA if we decide to
>>>>>> remove this.
>>>>>> Thanks
>>>>>> On 2023-08-22 15:01, Rohit Yadav wrote:
>>>>>>> +1 it's a broken feature that at least doesn't work with MySQL 8.x,
>>>>>>> I'm not sure if it worked with prior versions of MySQL. However, we
>>>>>>> need to document some sort of suggested MySQL HA setup in our docs.
>>>>>>> Regards.
>>>>>>> 
>>>>>>> From: Nux 
>>>>>>> Sent: Tuesday, August 22, 2023 18:54
>>>>>>> To: us...@cloudstack.apache.org ; Dev
>>>>>>> 
>>>>>>> Subject: [Consultation] Remove DB HA feature (db.ha.enabled)
>>>>>>> Hello everyone,
>>>>>>> A few weeks ago I asked you if you use or managed to use the DB HA
>>>>>>> Cloudstack feature (db.ha.enabled)[1] and after reading some of the
>>>>>>> replies and doing intensive testing myself I have found out that
>>>>>>> the
>>>>>>> feature is indeed non-functional, it's broken.
>>>>>>> In my testing I discovered DB HA can easily be done outside of
>>>>>>> Cloudstack by employing load balancers and other techniques.
>>>>>>> Personally I have achieved that by using Haproxy in front of Galera
>>>>>>> cluster, but also introduced Keepalived (vrrp) in my setup to
>>>>>>> "balance"
>>>>>>> multiple Haproxies which also worked well.
>>>>>>> As such, since the feature is basically broken, it will not be
>>>>>>> trivial
>>>>>>> to fix it and there are better ways of doing HA, then I propose to
>>>>>>> remove it altogether.
>>>>>>> Thoughts? Anyone against it?
>>>>>>> Cheers
>>>>>>> [1] -
>>>>>>>
>> https://docs.cloudstack.apache.org/en/latest/adminguide/reliability.html#database-high-availability
>>

Re: [PROPOSE] ACS 4.19.0.0 release

[Rohit Yadav]

Thanks for the proposal Abhishek, sounds good to me. Looking forward to 4.19!



Regards.


From: Abhishek Kumar 
Sent: Thursday, August 17, 2023 22:47
To: dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org 
Subject: [PROPOSE] ACS 4.19.0.0 release

Hi,

Thanks all for your support on my 4.19 RM proposal thread!

I propose the following timeline for the 4.19.0.0 release. Keep in mind 
4.18.1.0 release work is also currently in progress and is being managed by Wei.

- (8 plus weeks) Ongoing – Mid-October 2023: Accept all bugs, issues, 
improvements allowed in LTS [1]
- (1 week) Stabilise the main (or 4.19) branch, accept only critical/blocker 
issues (if any)
- End October 2023 and onwards: Cut 4.19.0.0 RC1 and further RCs if necessary, 
start/conclude vote, and finish release work

I hope to get support from all active contributors during the process of 
reviewing/testing/merging the PRs. You can find the open issues and PRs at the 
4.19.0.0 Github milestone [2]. Ping me (@shwstppr) or Daan (@DaanHoogland) on 
your issues and PRs, that are to be included in 4.19.0.0.

Looking forward to your support on bug fixes, reviews, tests, etc. I'm happy to 
collaborate with others on the release management. Thanks.

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


Regards,
Abhishek





 

Re: [PROPOSE] ACS 4.18.1.0 release

[Rohit Yadav]

Thanks for the update Wei.


Regards.


From: Nux 
Sent: Tuesday, August 22, 2023 19:42
To: us...@cloudstack.apache.org 
Cc: dev@cloudstack.apache.org 
Subject: Re: [PROPOSE] ACS 4.18.1.0 release

Thanks for the update, Wei.
Good job so far!

On 2023-08-21 12:48, Wei ZHOU wrote:
> Hi all,
>
> In the last weeks, we have merged a few bug fixes into the 4.18 branch.
> We
> are still working on remaining bug fixes and reviewing pull requests.
>
> 22 pull requests are open for review:
> https://github.com/apache/cloudstack/pulls?q=is%3Aopen+is%3Apr+milestone%3A4.18.1.0
>
> 51 issues are open (including 2 critical , 15 major, 33 minor issues):
> https://github.com/apache/cloudstack/issues?q=is%3Aopen+is%3Aissue+milestone%3A4.18.1.0
>
> *The code freeze time of 4.18.1.0 will be 12:00pm UTC (1pm BST, 2pm
> CEST),
> 28th August*.  The open pull requests and issues after code freeze will
> be
> moved to 4.18.2.0 milestone.
>
> -Wei
>
>
>

 

> On Wed, 2 Aug 2023 at 03:22, Wei ZHOU  wrote:
>
>> Hi all,
>>
>> Here is an update of Apache CloudStack 4.18.1.0 release:
>>
>> There are some open PRs and issues on github:
>>
>> 37 pull requests are open for review:
>> https://github.com/apache/cloudstack/pulls?q=is%3Aopen+is%3Apr+milestone%3A4.18.1.0
>>
>> 66 issues are open (including 1 BLOCKER, 1 critical , 18 major, 39
>> minor
>> issues):
>> https://github.com/apache/cloudstack/issues?q=is%3Aopen+is%3Aissue+milestone%3A4.18.1.0
>>
>>
>> We are busy with them. The processes need to be postponed for 2-4
>> weeks.
>>
>>
>> -Wei
>>
>>
>>
>>
>> On Thu, 4 May 2023 at 10:34, Wei ZHOU  wrote:
>>
>>> 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: [Consultation] Remove DB HA feature (db.ha.enabled)

[Rohit Yadav]

Shiv, Lucian, all,

It's a known limitation for all available MySQL clustering solutions such as 
Galera, Percona XtraDB, Innodb Cluster that GET_LOCK [1] isn't supported 
[2][3]. The GET_LOCK is used by CloudStack for global locking critical code 
when more than one management server(s) are running against the same 
database/server.

(MySQL NDB, InnoDB cluster could be something to experiment, as well as, coming 
up with a locking service framework which could help get around the 
mysql/native get_lock limitations).

[1] 
https://dev.mysql.com/doc/refman/8.0/en/locking-functions.html#:~:text=MySQL%20enforces%20a%20maximum%20length,lock%20with%20the%20same%20name.

[2] https://mariadb.com/kb/en/mariadb-galera-cluster-known-limitations/

[3] https://docs.percona.com/percona-xtradb-cluster/8.0/limitation.html



Regards.


From: Nux 
Sent: Tuesday, August 22, 2023 20:12
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org ; K B Shiv Kumar 

Subject: Re: [Consultation] Remove DB HA feature (db.ha.enabled)

But what do you think of the removal of DB HA code?

When using Galera you need to query against a single node, don't spread
the load among all 3, as this will break certain locking functionality
in Cloudstack and lead to problems.

In a Haproxy configuration you should be keeping just one active, eg:
 server galera1 10.0.3.2:3306 check
 server galera2 10.0.3.3:3306 check backup
 server galera3 10.0.3.4:3306 check backup

Regards

On 2023-08-22 15:36, K B Shiv Kumar wrote:
> We faced some issues when running Galera. We went back to master slave.
>
> Anyone using Galera in production for a long time?
>
> Regards,
> Shiv
>
>
 

> On 22-Aug-2023, at 19:34, Nux  wrote:
>>
>> Happy to contribute a doc on how to achieve HA if we decide to remove
>> this.
>>
>> Thanks
>>
>> On 2023-08-22 15:01, Rohit Yadav wrote:
>>> +1 it's a broken feature that at least doesn't work with MySQL 8.x,
>>> I'm not sure if it worked with prior versions of MySQL. However, we
>>> need to document some sort of suggested MySQL HA setup in our docs.
>>> Regards.
>>> 
>>> From: Nux 
>>> Sent: Tuesday, August 22, 2023 18:54
>>> To: us...@cloudstack.apache.org ; Dev
>>> 
>>> Subject: [Consultation] Remove DB HA feature (db.ha.enabled)
>>> Hello everyone,
>>> A few weeks ago I asked you if you use or managed to use the DB HA
>>> Cloudstack feature (db.ha.enabled)[1] and after reading some of the
>>> replies and doing intensive testing myself I have found out that the
>>> feature is indeed non-functional, it's broken.
>>> In my testing I discovered DB HA can easily be done outside of
>>> Cloudstack by employing load balancers and other techniques.
>>> Personally I have achieved that by using Haproxy in front of Galera
>>> cluster, but also introduced Keepalived (vrrp) in my setup to
>>> "balance"
>>> multiple Haproxies which also worked well.
>>> As such, since the feature is basically broken, it will not be
>>> trivial
>>> to fix it and there are better ways of doing HA, then I propose to
>>> remove it altogether.
>>> Thoughts? Anyone against it?
>>> Cheers
>>> [1] -
>>> https://docs.cloudstack.apache.org/en/latest/adminguide/reliability.html#database-high-availability

Re: [Consultation] Remove DB HA feature (db.ha.enabled)

[Rohit Yadav]

+1 it's a broken feature that at least doesn't work with MySQL 8.x, I'm not 
sure if it worked with prior versions of MySQL. However, we need to document 
some sort of suggested MySQL HA setup in our docs.


Regards.


From: Nux 
Sent: Tuesday, August 22, 2023 18:54
To: us...@cloudstack.apache.org ; Dev 

Subject: [Consultation] Remove DB HA feature (db.ha.enabled)

Hello everyone,

A few weeks ago I asked you if you use or managed to use the DB HA
Cloudstack feature (db.ha.enabled)[1] and after reading some of the
replies and doing intensive testing myself I have found out that the
feature is indeed non-functional, it's broken.

In my testing I discovered DB HA can easily be done outside of
Cloudstack by employing load balancers and other techniques.
Personally I have achieved that by using Haproxy in front of Galera
cluster, but also introduced Keepalived (vrrp) in my setup to "balance"
multiple Haproxies which also worked well.

As such, since the feature is basically broken, it will not be trivial
to fix it and there are better ways of doing HA, then I propose to
remove it altogether.

Thoughts? Anyone against it?

Cheers

[1] -
https://docs.cloudstack.apache.org/en/latest/adminguide/reliability.html#database-high-availability

 

[DISCUSS] Simplifying constructs and UX

[Rohit Yadav]

All,

Request for comments on following ideas, largely in the UI:

  1.  Does it make sense to simply the Default View as a Project which cannot 
be deleted and primary space for the Account. Essentially, the default view is 
the logged in account/user's project with no other collaborators

  2.  Migrate all isolated network constructs as VPC with a single tier.

  3.  Simplify templates/isos that are listed in deploy VM form: as a user, the 
template/iso section of the deploy VM form is complicated, would it make sense 
to simplify the template/iso shown as groups of guest OS family (like several 
other portals) and templates uploaded/registered by the account separately.

  4.  Remove data disk from VM deploy form, or hide it by default (show a 
button - add volume):
Currently, the deploy VM form only supports one data disk, however API can 
multiple disks. One can always still use APIs, but deploy VM and later attach 
more disks; or deploy vm but not start it, attach as many data disks as we want 
and then start it.

  5.  Show user-data and affinity (placement) groups as a first-class step, not 
hidden under advanced menu.

  6.  Offering groups or bundles: introduce way to group/bundle compute/data 
offerings; for example, I want to see CPU optimised offerings, memory 
optimiised offerings, specialised offerings (say GPU) etc.


Regards.

 

[DISCUSS] Fixing npm version for building UI

[Rohit Yadav]

All,

Our UI building in packages/PRs uses npm v14, while the current LTS version is 
v18. However, since we use npm for only development and building the UI 
statically there are hopefully no concerns around security and support.

I've been using both v14 and v16 to build UI across different branches that 
haven't EOL'd. With npm v16 and ACS 4.18, I'm not able to npm install and npm 
run serve without the following:

export NODE_OPTIONS=--openssl-legacy-provider


npm also is trying to change the package-lock file with a new format, 
considering this should we consider moving to support the latest LTS (v18) or 
switch to another UI pkg building tool (such as yarn)? Thoughts?


Regards.

 

Re: CentOS9 going to kernel panic mode

[Rohit Yadav]

Perhaps try with a different ISO build again, it could be an issue with the ISO 
- have you tested if it works say on VirtualBox, or VMware fusion/workstation?


Regards.


From: Stanley Burkee 
Sent: Tuesday, August 1, 2023 19:12
To: dev@cloudstack.apache.org 
Subject: Re: CentOS9 going to kernel panic mode

Screenshot link given below

https://drive.google.com/file/d/1ijpRW1ojwDyVYoErN5dWfa6C229zjNN3/view?usp=drive_link

On Tue, Aug 1, 2023 at 6:54 PM Stanley Burkee 
wrote:

> Hi Rohit,
>
> Thanks for your support
> The issue is consistent with multiple CPU offerings. I have used 4C4R,
> 4C8R, 8C8R & 8C16R CPU & RAM offerings.
>
> Best Regards
>
> Stanley
>
>
> On Tue, Aug 1, 2023 at 6:52 PM Rohit Yadav 
> wrote:
>
>> Hi Stanley, is it consistent even if you use a service offering with
>> large enough CPU and memory? Are you booting the VM in uefi or normal mode?
>>
>>
>> Regards.
>>
>> 
>> From: Stanley Burkee 
>> Sent: Tuesday, August 1, 2023 18:50
>> To: us...@cloudstack.apache.org ;
>> dev@cloudstack.apache.org 
>> Subject: CentOS9 going to kernel panic mode
>>
>> Hi Guys,
>>
>> Greetings
>> I am using Cloudstack 4.18 in my testing environment. I am using Rocky 8.7
>> as compute host with KVM.
>>
>> Whenever I create centOs9 from iso, it goes into kernel panic mode—and
>> facing the same issue with other Linux 9 kernel flavours also.
>>
>> Thanks a lot in advance.
>>
>>
>> Beast regards
>>
>> Stanley
>>
>>
>>
>>

 

Re: CentOS9 going to kernel panic mode

[Rohit Yadav]

Hi Stanley, is it consistent even if you use a service offering with large 
enough CPU and memory? Are you booting the VM in uefi or normal mode?


Regards.


From: Stanley Burkee 
Sent: Tuesday, August 1, 2023 18:50
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Subject: CentOS9 going to kernel panic mode

Hi Guys,

Greetings
I am using Cloudstack 4.18 in my testing environment. I am using Rocky 8.7
as compute host with KVM.

Whenever I create centOs9 from iso, it goes into kernel panic mode—and
facing the same issue with other Linux 9 kernel flavours also.

Thanks a lot in advance.


Beast regards

Stanley

 

Re: [Proposal] Object Storage in CloudStack

[Rohit Yadav]

Thanks for proposal the design doc Kishan, LGTM. Looking forward to experiment 
with the draft PR and iterations for further feedback.


Regards.


From: Kishan Kavala 
Sent: Tuesday, June 6, 2023 14:13
To: dev@cloudstack.apache.org 
Subject: [Proposal] Object Storage in CloudStack

Hi,
I would like CloudStack to support Object Storage as a first-class end user 
feature. It can be added using plugin framework to support various Object 
Storage providers.
CloudStack will manage the lifecycle of ObjectStoragePools and Buckets. Any S3 
compliant client should be able to manage the objects within the buckets.

I've added a draft functional spec here:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/%5BDRAFT%5D+CloudStack+Object+Store

Looking forward to your feedback.

regards,
Kishan





 

Re: [proposal] Consistency of naming in Cloudstack

[Rohit Yadav]

+1 As long as we're not changing API names which would break backward 
compatibility, I think having clear, intuitive and consistent names and 
terminology in CloudStack UI and documentation for resources is a good idea and 
will be greatly improve and polish CloudStack.

Historically, the word VM was never meant for compute instances like it is 
today. In computing, VM would refer to a virtual machine emulator which we can 
still see in the JVM, Erlang's Beam, etc also referred to as process virtual 
machines. What we think are VMs (thanks to VMware's product and marketing) 
popular much later on were system domains or system virtual machines that can 
emulate a whole computer system. Some hypervisors historically and still today 
(KVM, Xen/XCP-ng...) refer to them as domains. When these remote machines, 
jails or sometimes domains started running in headless remote environments 
(data centers), they were referred to as virtual personal server (VPS) or just 
virtual servers and eventually cloud or compute instances. I think the word 
compute instance or instance are quite popular, clear and intuitive word when 
used in an IaaS/cloud platform (in all opensource, closed cloud platforms and 
on public providers).

In the UI, historically and in recent times, we've always referred to VMs as 
"instances". In the legacy and current UI, the VM tab was/is called "Instances" 
under the Compute group, and most of the VM actions forms also refer on 
instances such as - edit/start/stop/reboot/reinstall/migrate instance. However, 
in documentation we sometimes refer instance to a VM and otherwise instance in 
other places. I wouldn't want to change the reference in the UI, so ideally 
some labels in the UI and docs should be fixed instead.

Despite our passionate thoughts, we can't honestly expect industry to follow us 
or adopt terminologies that we define. As an active participant we should use 
terms that are in the best of CloudStack project and the user community.

I think all user-facing things should be clear and consistent, without 
consistency as a new user I may be confused when say referring the CloudStack 
documentation and the UI. Most users I think start with both UI (and docs).


Regards.


From: Daan Hoogland 
Sent: Thursday, June 8, 2023 20:46
To: dev@cloudstack.apache.org 
Subject: Re: [proposal] Consistency of naming in Cloudstack

Giles, the principle of what you are saying seems good but I have a few remarks;
1. Consistency should not become a goal. Clarity is and if context
might give rise to a different understanding of the same work
consistency is detrimental to understanding
2. Metaphor is an important aspect in system development [1] first
introduced into software development in xtreme programming [2] I think
instance is a bad metaphor to use for Virtual Machine Instances in a
system that is full of all kinds of items (first class citizens) that
can also be seen as instances. I would go for "VM instance",
"VM-instance" or just machines. I am not saying either of these are
ideal but they are all better than instance.

and finally
3. The industry standard is not a good reason to go for a term. we can
improve on the industry standard and so we should.

€0.02

[1] 
https://medium.com/swlh/the-importance-of-metaphors-in-programming-philosophy-and-trading-a0030ed176b6
[2] http://www.extremeprogramming.org/rules/metaphor.html

On Thu, Jun 8, 2023 at 4:47 PM Giles Sirett  wrote:
>
> Background
> Recently, I have been looking at a  number of issues relating to the "first 
> use" / "first impression" use of cloudstack.  What to people think of 
> Cloudstack as a new user? What is peoples perception of Cloudstack as a new 
> user ? How easy is it for people to understand cloudstack & its concepts and 
> to get help
>
>
> One thing I have seen is that CloudStack is inconsistent with what we call 
> VM's/Instances:
>
>
>   *   In the UI main menu, we say Instances. We then have a very large 
> "Create instance" button. All lifecycle operations are then  "Foo Instance"
>   *   In various other places in the UI (many text messages, error messages,  
> column headers,  for example) we say "VM"
>   *   The API uses Instance, VM and Virtual Machine
>   *   The documentation, again, uses all 3 terms
>
> Now - I know everybody on this list (myself included for the last 10 years) 
> has always used these terms interchangeably  - we all KNOW that these are the 
> same things. However, I think it could cause confusion to people seeing 
> Cloudstack for the first time and create negative impressions. Also, there is 
> no consistency when searching documentation - one page uses one term, one the 
> other (and some even use both on the same page) .  I don't know of many other 
> pieces of software that use 2/3 different names for their  primary functional 
> object
>
>
> My proposal is to move towards having consistency of this naming  and would 
> look something like this:
>
>
>   1.  

Re: [DISCUSS] Upgrading Mockito & phasing out powermock

[Rohit Yadav]

Your approach LGTM Vishes, and we need to ensure build stability and smoketests 
continue to pass as-is. It would be great if unit tests using powermock runner 
are refactored or supported/counted in the codecoverage.


Regards.


From: Daan Hoogland 
Sent: Tuesday, June 6, 2023 18:18
To: dev@cloudstack.apache.org 
Subject: Re: [DISCUSS] Upgrading Mockito & phasing out powermock

I like your approach Vishesh +1 from me

On Tue, Jun 6, 2023 at 2:18 PM Vishesh Jindal
 wrote:
>
> Hi all,
>
> I am working on upgrading Mockito's version & phasing out powermock. For new 
> maven modules, I would request all to use Mockito's mockStatic instead of 
> Powermock.
>
> Why?
> Powermock's last release was on Nov 2, 2020. The project seems to have been 
> abandoned. Powermock has compatibility issues with Mockito's latest version 
> as well.
>
> How?
> The only usage for PowerMock I could see in code was for mocking static 
> methods. Since Mockito v3.4.0, it has the capability to mock static methods.
> I plan to migrate tests to Mockito's mockStatic instead of PowerMock. This 
> will have to be done module by module and will take some time.
>
> I have prepared a PR here: https://github.com/apache/cloudstack/pull/7577
>
> This PR upgrades mockito from v3.2.4 to v3.12.4 and removes the usage of 
> PowerMock from utils module.
>
>
> Let me know if you have any questions/concerns.
>
> Regards,
> Vishesh
>
>
>
>


--
Daan

 

Re: [VOTE] Upgrade Log4j to Log4j2

[Rohit Yadav]

João,

Technically, for lazy consensus a vote thread needs three +1 (binding) votes 
which are only counted towards a decision or approval [1].

Since there are no objections but concerns shared so far, the PR can be 
reviewed, tested and merged as any other PR as long as it meets the community 
review and merge guidelines, in this case since the PR is a large one I would 
request additional manual QA and upgrade tests be done to ensure there is no 
stability/upgrade regression(s).

[1] 3.2.1: https://cloudstack.apache.org/bylaws.html


Regards.


From: João Jandre Paraquetti 
Sent: Tuesday, June 6, 2023 01:36
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Subject: Re: [VOTE] Upgrade Log4j to Log4j2

Hi all,

This voting has been going on for quite some time already. In the
meantime, more tests have been done and the PR has been verified as
working with both mbx and BO.

As we did not get any -1 votes, and achieved the minimum of three +1s, I
will therefore close this vote and propose we proceed in the PR. Any
remaining issues people might have with the PR can be addressed in the
PR's discussions in github, so that we can finally merge the PR.

Best regards,
João Jandre (JoaoJandre)

On 18/05/2023 17:29, Sidimar Carniel wrote:
> Important effort in this work!
>
> [ ] +1 approve
>
> Regards,
> Sidimar Carniel
>
>
>
> Em qua., 17 de mai. de 2023 às 10:27, Rodrigo D. Lopez <
> rodrigoduartelo...@gmail.com> escreveu:
>
>> Thanks for the great work!
>>
>> Based on discussions in PR and the discussion thread[1]. My vote is +1.
>>
>> Log4j v1 (deprecated) and its current alternative reload4j in use in ACS
>> are not ideal for the long run. Therefore, for the future of ACS, and to
>> enable us to keep evolving, the upgrade is most welcome.
>>
>> Regards,
>> Rodrigo Lopez
>>
>> [1]  https://lists.apache.org/thread/261j7m0p5mr4q7yclvo49mwhkxz4yov2
>>
>> Em qua., 17 de mai. de 2023 às 09:41, Daan Hoogland <
>> daan.hoogl...@gmail.com>
>> escreveu:
>>
>>> -0
>>>
>>> Joao, Daniel reacted negatively to my question to create a proxy with bad
>>> arguments and I had no time to respond yet. I think not adding a proxy at
>>> this time is a missed opportunity and I would full heartedly +1 if we
>> had.
>>> Not creating a proxy class (with or without configurability) is a waste
>> of
>>> your effort.
>>> All the standardisation of calls is very useful irrespective.
>>>
>>> On Tue, May 16, 2023 at 8:45 PM Daniel Salvador >>
>>> wrote:
>>>
 Hello, João

 Considering the discussion we had in the thread[1] and that the
>> conflicts
 will be mostly regarding loggers names (which is simple to fix), I am
>> +1
>>> on
 the proposal.

 Best regards,
 Daniel Salvador (gutoveronezi)

 [1] https://lists.apache.org/thread/261j7m0p5mr4q7yclvo49mwhkxz4yov2

 On Tue, May 16, 2023 at 1:28 PM João Jandre Paraquetti <
 j...@scclouds.com.br>
 wrote:

> Hello guys,
>
> I am opening this voting thread as result of the discussion in thread
> "ACS upgrade to Log4J2 version 2.19"[1].
>
> The voting aims to continue the efforts and conclude the upgrade of
>> the
> ACS logging library to Log4j2 through PR 7131[2]; merge the PR as
>> soon
> as possible and provide ways to contributors solve the conflicts
>>> easily,
> so all the contributors have time to fix their merge conflicts before
> 4.19; announce that change in the release notes and provide ways to
> users upgrade their customization made to the default log4j
> configuration files.
>
> 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)
>
> Best regards,
> João Jandre (JoaoJandre)
>
> [1] https://lists.apache.org/thread/261j7m0p5mr4q7yclvo49mwhkxz4yov2
> [2] https://github.com/apache/cloudstack/pull/7131
>
>
>>>
>>> --
>>> Daan
>>>

 

Re: ACS upgrade to Log4J2 version 2.19

[Rohit Yadav]

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 wo

Re: [DISCUSS] CloudStack Website build and modernisation

[Rohit Yadav]

All,

The blog has been migrated now with redirects in place as well: 
https://cloudstack.apache.org/blog/

For now the blog is being manually built from the docusauras-staging branch and 
its assets and blog content are copied to the asf-site branch. This will be 
fixed by a Github Actions automation once the website is fully migrated.

Please continue to review and test the staging site at 
https://cloudstack.staged.apache.org/ and report/suggest at 
https://github.com/apache/cloudstack-www/issues


Thanks and regards.


From: Rohit Yadav 
Sent: Wednesday, May 3, 2023 21:34
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Cc: priv...@cloudstack.apache.org 
Subject: Re: [DISCUSS] CloudStack Website build and modernisation

Ivet, All,

Thanks for reporting and suggesting. The mailing list strips off 
attachments/images, may I ask to report any/all outstanding issues, 
enhancements, and features for the website here to help us track and address 
them in a structured manner:
https://github.com/apache/cloudstack-www/issues


My proposal is to have us log issues on the above-mentioned Github issue 
tracker link for the website, and triage the issues and work on the blockers 
(and whatever bandwidth/time permits).


In the meanwhile, I'll add some documentation on how to work with the staging 
website for both technical and non-technical contributors. I think we can use 
Github and/with a headless CMS that is asf-compliant.


If we don't have any objections and blockers, I'll start a proposal/vote on the 
migration of the staging site as our project website around mid-may as the 
asf-infra mandated deadline is 31st May '23.


Regards.


From: Ivet Petrova 
Sent: Wednesday, May 3, 2023 18:09
To: us...@cloudstack.apache.org 
Cc: dev@cloudstack.apache.org ; 
priv...@cloudstack.apache.org 
Subject: Re: [DISCUSS] CloudStack Website build and modernisation

I am volunteering to do a check and comparison between the old pages and new 
pages in the next 2 weeks.

- As for the icons - I suggest we get some from freepik or Fontawesome?
Please see these:
https://fontawesome.com/icons/linkedin?f=brands=solid
https://fontawesome.com/icons/square-twitter?f=brands=solid
https://fontawesome.com/icons/youtube?f=brands=solid
https://fontawesome.com/icons/square-github?f=brands=solid


- As for the header - You want to keep it as the existing one, but I see a 
whole new section for Learn More about ACS with Case Studies and other docs. As 
we have this as a change on the home page, what is the concern of changing the 
header too?

I would like to propose two options for how it shall look. Both options will 
make the website front page to look more professional and polished. This is 
quite important as this is the first user interaction with the website and 
specifically for people new to the technology it will make an impression.
In both options you have a simple background image + text as overlay. I am 
attaching the background images for a discussion.

Also it is good to have some nice Title and H1 on home page (title and subtitle 
in the header). These are affecting the website SEO performance and 
optimisation and can help us to go up in the search result when users are 
searching for a solution. I am proposing the following copies for the header:

Ttile: Flexible, easy-to-use and powerful open-souce Infrastructure as a 
Service cloud computing platform
H1: Apache CloudStack is used by a number of cloud providers, telecoms, MSPs 
and enterprises around the world! Proven to be reliable to manage tens of 
thousands of physical servers installed in geographically distributed 
datacenters.

As a main CTA, it will be good if we have just one button in the header - the 
Download one, so that people have a clear action to do and not wondering 
between two options. If you compare to other technologies websites, most of the 
big vendors and our main competitor have a clear single CTA in the header.

[cid:FD241238-4C5C-4347-84FD-0774200C9975]


[cid:DBCD2BA6-86B3-419C-9243-6D3628085204]


Kind regards,










 

On 3 May 2023, at 15:06, Rohit Yadav 
mailto:rohit.ya...@shapeblue.com>> wrote:

Thanks again for another iteration of the review Ivet;

 *   I wouldn't in this iteration change too many graphics/design elements, 
I've tried to keep the staging website more or less similar to the current 
website in terms of layout, content. I would suggest that we can do this later 
(in fact I wouldn't be able to assist, if there are graphics/svg I can help 
replace - but I think the project website should keep its trademark'd 
logo/banner as-is without changes on the homepage).

 *   I've removed the social media link from the menu bar. I can revisit adding 
them to the footer (I need to find which icons library it supports that I can 
use).

 *   I've already acknowledged on the blog categories as a TODO item. However, 
I don't think it's a blocker. I don'

Re: ACS upgrade to Log4J2 version 2.19

[Rohit Yadav]

ve 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
> > > loggers, which the fixes can be easily automated via scripts. For the
> > > efforts on the release management, I am pretty sure some colleagues
> from
> > > the community would be glad to help as well.
> > >
> > > We understand the process and everybody seems to agree on this step
> > > forward; is there any technical reason not to? Anyone else have
> thoughts
> > on
> > > this?
> > >
> > > Best regards,
> > > Daniel Salvador (gutoveronezi)
> > >
> > > [1] docker run -v /tmp:/mnt/build -v ~/.m2:/root/.m2 -e "USER_ID=$(id
> > -u)"
> > > -e "USER_GID=$(id -g)" -e "ACS_BUILD_OPTS=-Dnoredist"
> > > scclouds/cloudstack-deb-builder:ubuntu2004-jdk11-python3 --git-remote
> > > https://github.com/apache/cloudstack.git --git-ref refs/pull/7131/head
> > > [2] docker run -v /tmp:/mnt/build -v ~/.m2:/root/.m2 -e "USER_ID=$(id
> > -u)"
> > > -e "USER_GID=$(id -g)"  scclouds/cloudstack-rpm-builder:centos7-jdk11
> > > --distribution centos7 --pack noredist --git-remote
> > > https://github.com/apache/cloudstack.git --git-ref refs/pull/7131/head
>