Re: [VOTE] Apache CloudStack 4.19.1.0 (RC1)

2024-07-11 Thread Nux

Rohit,

That's a very good point about the routines, thanks for sharing how to 
restore them.

Hope your marriage is intact after this little adventure. :)

I'll be doing some testing shortly.

On 2024-07-11 12:52, Rohit Yadav wrote:

+0 (binding)


  *
Tested fresh installation of EL8 packages, deployed VM from newly 
created template on a newly created network; tested VM, volume & 
network lifecycles using both mbx & health check tests passing 
w/Trillian/BO

  *
Tested upgrade from 4.19.0.2 EL8 to 4.19.1.0 RC1 EL8 pkgs using mbx; 
tested upgrading systemvms, VRs (with/without cleanup and live patch on 
an isolated network; deployed new VM & volumes and tested old ones)

  *
Felt dangerous and upgraded my CloudStack 4.19.0.2 homelab to 4.19.1.0 
RC1 using deb packages (hope there are no major blockers to piss off 
wife :))

 *
Upgrade went OK on the three Ubuntu 22.04 based 3xKVM hosts
 *
I hit an issue with idempotent routines missing on cloud_usage db 
(borrowed them from mbx env with: mysqldump --no-create-db 
--no-create-info --no-data --routines cloud_usage > 
cloud_usage-routines.sql ; and applied this in my homelab env; likely 
my fault while moving DB servers and forgot the -R option where I 
forgot to backup the routines)

 *
Tested homelab storage: nfs, local storage & ceph - OK; hosts upgraded 
OK;

 *
Post upgrade, after deleting systemvms I found the SSVM & CPVM starting 
to be stuck. I restarted the mgmt server and after a while the SSVM 
came up but the CPVM was stuck. I repeated the same, but again SSVM 
came up but CPVM struggle and after a few agent restarts it came up 
eventually.

 *
Post this, tested several VM, volume and network lifecycles worked OK

I've logged the issue here - 
https://github.com/apache/cloudstack/issues/9371 to triage further if 
it's an issue in RC1 or to help investigate if it was an env issue. I'm 
happy to change my vote to a +1 if it's just my env issue.



Regards.





From: Suresh Kumar Anaparti 
Sent: Wednesday, July 10, 2024 17:45
To: dev ; users 


Subject: [VOTE] Apache CloudStack 4.19.1.0 (RC1)

Hi All,

I have created a 4.19.1.0 release (RC1), with the following artifacts 
up

for testing and a vote:

Git Branch and Commit SHA:
https://github.com/apache/cloudstack/tree/4.19.1.0-RC20240710T1604
Commit: 2dbd80d692d6f5a207f90a07ac0b7583a41b71cd

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

PGP release keys (signed using 
D6E0581ECF8A2FBE3FF6B3C9D7CEAE3A9E71D0AA):

https://dist.apache.org/repos/dist/release/cloudstack/KEYS

The vote will be open until 16th July 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 reason why)

For users convenience, the packages from this release candidate (RC1) 
and

4.19.1.0 systemvm templates are available here:
https://download.cloudstack.org/testing/4.19.1.0-RC1/
https://download.cloudstack.org/systemvm/4.19/

Regards,
Suresh


Re: CCC2024 Funding - Important

2024-07-10 Thread Nux

Very well said, Rohit.


On 2024-07-10 10:22, Rohit Yadav wrote:

Hi Ivet, all,

Thanks for starting this thread. While my work organisation, ShapeBlue, 
has been participating and sponsoring the CCC every year, I think it's 
important for all organisations who use CloudStack and benefit from 
CloudStack to make such conferences and events sustainable and funding 
and sponsoring is an obvious way to do that.


Having CCC not only allow all of us to meet in person, attend talks, 
learn and collaborate with each other, this also serves as a constant 
heartbeat for the community and a platform to discuss, build consensus 
and drive the future of the project and for anybody considering or 
using CloudStack to network, discover and learn about the project and 
its community.


Regards.

Regards.




From: Ivet Petrova 
Sent: Tuesday, July 9, 2024 12:53:56 PM
To: us...@cloudstack.apache.org 
Cc: dev ; Apache CloudStack Marketing 


Subject: Re: CCC2024 Funding - Important

As a follow up - as the attachment is no visible, sponsorship packages 
can be seen here: 
https://www.cloudstackcollab.org/wp-content/uploads/2024/04/Sponsorship-Prospectus-CCC24-web.pdf



Best regards,




On 9 Jul 2024, at 10:09, Ivet Petrova  
wrote:


Hello all,

I would like to bring in a serious topic for the yearly CloudStack 
Collaboration Conference 2024.
I would like to remind everyone, that the event is organised by a group 
of volunteers and we rely entirely on sponsorship from the community, 
so that we can organise the event.
Organising such event is a costly thing - we need to pay for venue, for 
video recording, catering, ad materials, promoting the event. On a 
daily basis, I get a lot of questions for free tickets and people 
really excited to join the event. On the other hand, we have just a few 
inquiries for sponsorship.
Finding more sponsors is something really vital, so that we can have 
the event. For this reason, I would ask for some community help - could 
you all evangelise for the event internally in your companies and help 
me find more sponsors?


I am attaching here the event sponsorship prospectus.
I do not want to sound too harsh, but we need funding in order to have 
an event. Otherwise, it will not be possible.




Best regards,


Re: [Proposal] Storage Filesystem as a First Class Feature

2024-07-05 Thread Nux

Rohit,

Your reply LGTM, a few more lines from me:
- initially the export is NFS, that's how users/VMs will consume it as, 
just clarifying, I know we want to keep this somewhat agnostic
- while there is no agent running there, as you noted, most of the stuff 
can be configured either via userdata, udev rules or a combination of 
both
- in terms of monitoring we could enable snmpd on the appliance and/or a 
prometheus system exporter




On 2024-07-05 08:01, Rohit Yadav wrote:

Proposed design doc largely LGTM.

 I've some additional suggestions and feedback to make requirements &  
the first phase implementation more clearer and simpler:



  *
+1 on implementing it in a hypervisor and storage agnostic manner.

  *
Let's have the FS VMs owned by the caller (account or project), not 
like a system-owned appliance. It would then be just like CKS in that 
sense. This is because there is nothing special about the feature as in 
users can't do it, it's really for (a) users who want the benefit of 
shared storage but don't want to setup themselves and (b) orchestrate 
such a feature via API/SDKs/automation. Advanced users may not prefer 
to use it who want too many customisation and complexities.


  *
To keep the first phase simple, let's drop adding support for 
metrics/usage of FS VM and any other lifecycle that would need an agent 
or need for the management servers to SSH/manage the FS VM at all. 
Then, the scope can be limited to:

 *
Orchestrate the initial FS VM setup that can be easily done via 
user-data (config drive or VR depending on the network, cloud-init can 
orchestrate NFS exports), the FS VM's nfs service can also listen on 
all nics/IPs. This would make adding the FS capability to work out of 
the box if somebody want to attach the FS to other networks later (than 
the one it was initially created on).

 *
Keep it simple: as there is no agent or mgmt server access needed or 
required; any change to the FS properties or lifecycle could be done by 
a FS VM reboot or recreation, as the FS VM is stateless and a separate 
data disk holds the file share storage. For such operations, the UI can 
clearly mention a warning or note that such an operation would cause 
downtime due to reboot/recreate lifecycle operation of the FS VM.

 *
Suggestions for the Lifecycle operations:
*
(*list & update API are given, should support pagination, listing by 
name/keyword, by network, account/domain/project etc)

*
Create FS: initial user-data base FS VM setup (during initial setup, 
disk can be check/formatted + mounted with fstab rules)

*
Recreate/restart FS: destroy & recreate FS VM, attach data disk before 
starting the VM (setup can check and initialise disk if needed; and 
grow/expand filesystem if underlying volume was resized).

*
Attach/detach FS (to/from network): simply CloudStack nic/network 
attach/detach (worth checking if cloud-init or something in the 
systemvm template automatically takes care of nic setup in the FS VM)

*
Expand FS size: this could be simply UI-based proxy to resizing data 
disk, but resizing would cause recreating (or rebooting) or the FS VM, 
for it to grow the FS (due to lack of agent or SSH access, this may be 
acceptable in the first phase)

*
Delete FS: deleting FS with/without expunging the data disk; and for 
users to recover a non-expunged FS (similar to VMs)

 *
FSM states: FS should have states that correspond to the FS VM running 
and state of the underlying data disk

 *
Misc: Ensure FS VM is HA enabled, worth also either assuming some 
default compute offering or allow caller to specify compute offering 
for the FS VM.

 *
Network support: support all networks except L2 or networks which don't 
have userdata & dhcp capabilities

 *
Hypervisor & Storage support: agnostic

*FS = File Shares (suggested name)


Regards.





From: Alex Mattioli 
Sent: Wednesday, June 19, 2024 15:13
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: RE: [Proposal] Storage Filesystem as a First Class Feature

+1 on that,  keeping it hypervisor agnostic is key.




-Original Message-
From: Nux 
Sent: Wednesday, June 19, 2024 10:14 AM
To: dev@cloudstack.apache.org
Cc: us...@cloudstack.apache.org
Subject: Re: [Proposal] Storage Filesystem as a First Class Feature

Thanks Piotr,

This is the second time virtio-fs has been mentioned and just 
researched it a bit, it looks like something really nice to have in 
Cloudstack, definitely something to look at in the future.


Nice as it is though, it has a big drawback, it's KVM-only, so for now 
we'll stick to "old school" tech that can be used in an agnostic 
matter.


You are more than welcome to share thoughts on the other details 
presented, perhaps pros/cons on filesystems and other gotchas you may 
have encountered yourself.


On 2024-06-19 07:04, Piotr Pisz wrote:

Hi,
W

Re: Issue in Setup KVM host with agent 4.18.1

2024-07-01 Thread Nux

Hello,

That's essentially an Ampere Altra server. You will need to share a lot 
more details.


This may also come in handy:
https://rohityadav.cloud/blog/cloudstack-arm64-kvm/


On 2024-06-26 08:07, Sanjay Kumar wrote:

Hi All,

Does the ARM RL300 server Support Cloudstack? We are facing while
installing the Cloudstack agent 4.18.1.0.

Any help would be really appreciated. Thank you!


Thank you
Sanjay Kumar


Re: [RESULT][VOTE] Apache CloudStack Kubernetes Provider 1.1.0 RC1

2024-06-25 Thread Nux

Indeed, good work, Vishesh!



On 2024-06-25 13:19, Rohit Yadav wrote:
Thanks and good work Vishesh and everyone involved in the maintenance 
release.



Regards.





From: Vishesh Jindal 
Sent: Tuesday, June 25, 2024 16:29
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: [RESULT][VOTE] Apache CloudStack Kubernetes Provider 1.1.0 RC1

Hi all,

After 120 hours, the vote for Apache CloudStack Kubernetes Provider 
1.1.0 *passes* with

3 PMC + 1 non-PMC votes.

+1 (PMC / binding)
3 person (Rohit, Wei, Nux)

+1 (non binding)
1 person (Kiran)

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 and publish images on dockerhub.






From: Rohit Yadav 
Sent: Tuesday, June 25, 2024 12:39 PM
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org ; Vishesh 
Jindal 

Subject: Re: [VOTE] Apache CloudStack Kubernetes Provider 1.1.0 RC1

Looks like the vote has reached lazy consensus, @Vishesh 
Jindal<mailto:vishesh.jin...@shapeblue.com> could we wrap up?



Regards.

Rohit Yadav
VP Engineering
rohit.ya...@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>







________
From: Nux 
Sent: Thursday, June 20, 2024 17:18
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: Re: [VOTE] Apache CloudStack Kubernetes Provider 1.1.0 RC1

+1 as well, based on similar test to Wei's.

Good job, Vishesh.

On 2024-06-20 12:34, Kiran Chavala wrote:

Hi Vishesh

+1

I tried the same steps as Wei did,  but deployed a cks cluster in a 
vpc

network tier with acl rule of default_allow

1. Create a CKS cluster with k8s 1.28.4 and Select a vpc network

2. Delete cloudstack-kubernetes-provider 1.0.0

kubectl delete -f
https://raw.githubusercontent.com/apache/cloudstack-kubernetes-provider/main/deployment.yaml

3.  Install 1.1.0-rc1

kubectl apply -f
https://github.com/apache/cloudstack-kubernetes-provider/releases/download/v1.1.0-rc1/deployment.yaml

4. Create nginx deployment and expose the service with
type=LoadBalancer.

kubectl  expose deploy/nginx-deployment3 --port=80 
--type=LoadBalancer.


The public ip is qcuired

kubectl  get svc
NAMETYPE   CLUSTER-IP  EXTERNAL-IP
PORT(S)AGE
kubernetes  ClusterIP  10.96.0.1   
443/TCP12m
nginx-deployment3   LoadBalancer   10.105.61.120   10.0.54.125
80:31053/TCP   7m37s



5.  Delete the nginx service.
Public IP is released

Regards
Kiran

From: Rohit Yadav 
Date: Thursday, 20 June 2024 at 12:04 PM
To: dev@cloudstack.apache.org ,
us...@cloudstack.apache.org 
Subject: Re: [VOTE] Apache CloudStack Kubernetes Provider 1.1.0 RC1
Lucian,

The convenience binary in case of this sub-project is the
docker/container image, users can test RC1 builds from:
https://hub.docker.com/r/apache/cloudstack-kubernetes-provider/tags


Regards.







________
From: Nux 
Sent: Thursday, June 20, 2024 04:03
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: Re: [VOTE] Apache CloudStack Kubernetes Provider 1.1.0 RC1

In community's interest, do we have binary packages anywhere, ie
deb/rpms?

Cheers

On 2024-06-19 07:12, Vishesh Jindal wrote:

Hi All,

I made a mistake and didn't create the release on dist.apache.org.
Please discard my previous email.

I've created a new CloudStack Kubernetes Provider 1.1.0 release 
(RC1),

with the following artifacts up for a vote:

Git Branch and Commit SHA:
https://github.com/apache/cloudstack-kubernetes-provider/tree/59c3e7b21c39eefb2306bb8504bcef901a9d
Commit: 59c3e7b21c39eefb2306bb8504bcef901a9d

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

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

For users convenience:
* docker hub -
https://hub.docker.com/r/apache/cloudstack-kubernetes-provider/tags

* Kubernetes manifest for the rc release:
https://github.com/apache/cloudstack-kubernetes-provider/releases/download/v1.1.0-rc1/deployment.yaml

Vote will be open for 120 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
Vishesh





From: Vishesh Jindal
Sent: Tuesday, June 18, 2024 6:36 PM
To: us...@cloudstack.apache.org ;
dev@cloudstack.apache.org 
Subject: [VOTE] Apache CloudStack Kubernetes Provider 1.1.0 RC1

Hi All,

I've created a 1.1.0 release (RC1) for Apache CloudStack Kubernetes
Provider, with the following artifacts up for
a vote:

Git Branch and Commit SH:
https://github.com/apache/cloudstack-kubernetes-provider/t

Re: [DISCUSS] Deprecate/remove support for EOL distros and hypervisors

2024-06-20 Thread Nux
By all means, remove CentOS7 and any EOL OS or component from the matrix 
and recommendations!


Regards

On 2024-06-20 11:45, Rohit Yadav wrote:

+ Users

Just to be clear, what this thread is about - Deprecating/removing 
documentation via the compatibility matrix for a component does not 
necessarily mean CloudStack will not work on it, in fact it might (with 
some additional pkg installation if required if we decide to transition 
to JRE17/21) and community's testing. The discussion is whether from a 
project point of view, what should users be advised that is considered 
supported via the compatibility matrix page in the release notes. The 
same applies for other distro/hosts, hypervisors, MySQL DB version.


Just a note for the community to be aware: EL7/CentOS7 active support 
has already ended in 2020, and we've already supported it since the 
last 3-4 years. It's only the security update/support ending by end 
June 2024. So, if there's any future/potential security issue around 
EL7, we will not be able to support that 18months moving forward (18 
months being typical ACS LTS release support period). That's risk, I 
think we logistically wouldn't be able to carry forward for the next 
major release (4.20) in Q3/Q4 '24.


Refer: https://endoflife.date/centos


Regards.





From: Nux 
Sent: Thursday, June 20, 2024 15:21
To: dev@cloudstack.apache.org 
Cc: Alex Mattioli 
Subject: Re: [DISCUSS] Deprecate/remove support for EOL distros and 
hypervisors


+1 what Alex said.
It's kind of wrong, but CentOS7 has such a large install base 
(generally

and for Cloudstack, too) that I feel deprecating it right away would be
a mistake.


On 2024-06-20 10:45, Alex Mattioli wrote:

I'd like if we keep EL7 for at least one more version, the transition
path out of that is clear now but many cloud operators haven't 
replaced

it yet.

On the rest +1




-Original Message-
From: Rohit Yadav 
Sent: Thursday, June 20, 2024 11:43 AM
To: dev@cloudstack.apache.org
Subject: [DISCUSS] Deprecate/remove support for EOL distros and
hypervisors

All,

Referencing
https://docs.cloudstack.apache.org/en/4.19.0.0/releasenotes/compat.html,
some of the distros and hypervisors we support have reached or 
reaching

EOL by end of this month.

Please review and advise how we should deprecating/remove the 
following

for the next 4.20 release (i.e. compatibility matrix for the future
4.20 release notes):

Distros:

  *
EL7 (CentOS 7, RHEL7, https://endoflife.date/centos)
  *
Ubuntu 18.04 (https://endoflife.date/ubuntu)


Software requirements:

  *
JRE 11 (Discuss - should we transition to support JRE/JDK 17 or 21, 
for

4.20? https://endoflife.date/oracle-jdk And are all supported distros
have a JRE17/21 package/dependency availalble)
  *
MySQL 5.6, 5.7 (https://endoflife.date/mysql)

Hypervisors:

  *
KVM: Ubuntu 18.04 (https://endoflife.date/ubuntu), EL7
(https://endoflife.date/centos)
  *
XenServer All versions except 8.x (retain note that it's not tested,
https://www.citrix.com/support/product-lifecycle/legacy-product-matrix.html)
  *
XCP-ng: All versions except 8.2/LTS (https://endoflife.date/xcp-ng)
  *
VMware: 6.5, 6.7 (https://endoflife.date/vcenter)


Regards.


Re: [VOTE] Apache CloudStack Kubernetes Provider 1.1.0 RC1

2024-06-20 Thread Nux

+1 as well, based on similar test to Wei's.

Good job, Vishesh.

On 2024-06-20 12:34, Kiran Chavala wrote:

Hi Vishesh

+1

I tried the same steps as Wei did,  but deployed a cks cluster in a vpc 
network tier with acl rule of default_allow


1. Create a CKS cluster with k8s 1.28.4 and Select a vpc network

2. Delete cloudstack-kubernetes-provider 1.0.0

kubectl delete -f
https://raw.githubusercontent.com/apache/cloudstack-kubernetes-provider/main/deployment.yaml

3.  Install 1.1.0-rc1

kubectl apply -f
https://github.com/apache/cloudstack-kubernetes-provider/releases/download/v1.1.0-rc1/deployment.yaml

4. Create nginx deployment and expose the service with 
type=LoadBalancer.


kubectl  expose deploy/nginx-deployment3 --port=80 --type=LoadBalancer.

The public ip is qcuired

kubectl  get svc
NAMETYPE   CLUSTER-IP  EXTERNAL-IP   
PORT(S)AGE
kubernetes  ClusterIP  10.96.0.1   
443/TCP12m
nginx-deployment3   LoadBalancer   10.105.61.120   10.0.54.125   
80:31053/TCP   7m37s




5.  Delete the nginx service.
Public IP is released

Regards
Kiran

From: Rohit Yadav 
Date: Thursday, 20 June 2024 at 12:04 PM
To: dev@cloudstack.apache.org , 
us...@cloudstack.apache.org 

Subject: Re: [VOTE] Apache CloudStack Kubernetes Provider 1.1.0 RC1
Lucian,

The convenience binary in case of this sub-project is the 
docker/container image, users can test RC1 builds from: 
https://hub.docker.com/r/apache/cloudstack-kubernetes-provider/tags



Regards.








From: Nux 
Sent: Thursday, June 20, 2024 04:03
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: Re: [VOTE] Apache CloudStack Kubernetes Provider 1.1.0 RC1

In community's interest, do we have binary packages anywhere, ie
deb/rpms?

Cheers

On 2024-06-19 07:12, Vishesh Jindal wrote:

Hi All,

I made a mistake and didn't create the release on dist.apache.org.
Please discard my previous email.

I've created a new CloudStack Kubernetes Provider 1.1.0 release (RC1),
with the following artifacts up for a vote:

Git Branch and Commit SHA:
https://github.com/apache/cloudstack-kubernetes-provider/tree/59c3e7b21c39eefb2306bb8504bcef901a9d
Commit: 59c3e7b21c39eefb2306bb8504bcef901a9d

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

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

For users convenience:
* docker hub -
https://hub.docker.com/r/apache/cloudstack-kubernetes-provider/tags

* Kubernetes manifest for the rc release:
https://github.com/apache/cloudstack-kubernetes-provider/releases/download/v1.1.0-rc1/deployment.yaml

Vote will be open for 120 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
Vishesh





From: Vishesh Jindal
Sent: Tuesday, June 18, 2024 6:36 PM
To: us...@cloudstack.apache.org ;
dev@cloudstack.apache.org 
Subject: [VOTE] Apache CloudStack Kubernetes Provider 1.1.0 RC1

Hi All,

I've created a 1.1.0 release (RC1) for Apache CloudStack Kubernetes
Provider, with the following artifacts up for
a vote:

Git Branch and Commit SH:
https://github.com/apache/cloudstack-kubernetes-provider/tree/v1.1.0-rc1

Commit: 774a144876d2c875c61becab00e0487692130302

Deployment manifest:
https://github.com/apache/cloudstack-kubernetes-provider/releases/download/v1.1.0-rc1/deployment.yaml

Docker image:
apache/cloudstack-kubernetes-provider:v1.1.0-rc1

Docker image manifest digest:
sha256:38dc0a4413657b9c88cdcb28ef330e49aee6fb972a4cbc4055a0608b9f8bf7b8

You can check the changelog for the release
here:https://github.com/apache/cloudstack-kubernetes-provider/releases/tag/v1.1.0-rc1

Vote will be open for 120 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
Vishesh


Re: [DISCUSS] Deprecate/remove support for EOL distros and hypervisors

2024-06-20 Thread Nux

+1 what Alex said.
It's kind of wrong, but CentOS7 has such a large install base (generally 
and for Cloudstack, too) that I feel deprecating it right away would be 
a mistake.



On 2024-06-20 10:45, Alex Mattioli wrote:
I'd like if we keep EL7 for at least one more version, the transition 
path out of that is clear now but many cloud operators haven't replaced 
it yet.


On the rest +1




-Original Message-
From: Rohit Yadav 
Sent: Thursday, June 20, 2024 11:43 AM
To: dev@cloudstack.apache.org
Subject: [DISCUSS] Deprecate/remove support for EOL distros and 
hypervisors


All,

Referencing 
https://docs.cloudstack.apache.org/en/4.19.0.0/releasenotes/compat.html, 
some of the distros and hypervisors we support have reached or reaching 
EOL by end of this month.


Please review and advise how we should deprecating/remove the following 
for the next 4.20 release (i.e. compatibility matrix for the future 
4.20 release notes):


Distros:

  *
EL7 (CentOS 7, RHEL7, https://endoflife.date/centos)
  *
Ubuntu 18.04 (https://endoflife.date/ubuntu)


Software requirements:

  *
JRE 11 (Discuss - should we transition to support JRE/JDK 17 or 21, for 
4.20? https://endoflife.date/oracle-jdk And are all supported distros 
have a JRE17/21 package/dependency availalble)

  *
MySQL 5.6, 5.7 (https://endoflife.date/mysql)

Hypervisors:

  *
KVM: Ubuntu 18.04 (https://endoflife.date/ubuntu), EL7 
(https://endoflife.date/centos)

  *
XenServer All versions except 8.x (retain note that it's not tested, 
https://www.citrix.com/support/product-lifecycle/legacy-product-matrix.html)

  *
XCP-ng: All versions except 8.2/LTS (https://endoflife.date/xcp-ng)
  *
VMware: 6.5, 6.7 (https://endoflife.date/vcenter)


Regards.


Re: [VOTE] Apache CloudStack Kubernetes Provider 1.1.0 RC1

2024-06-19 Thread Nux
In community's interest, do we have binary packages anywhere, ie 
deb/rpms?


Cheers

On 2024-06-19 07:12, Vishesh Jindal wrote:

Hi All,

I made a mistake and didn't create the release on dist.apache.org. 
Please discard my previous email.


I've created a new CloudStack Kubernetes Provider 1.1.0 release (RC1), 
with the following artifacts up for a vote:


Git Branch and Commit SHA:
https://github.com/apache/cloudstack-kubernetes-provider/tree/59c3e7b21c39eefb2306bb8504bcef901a9d
Commit: 59c3e7b21c39eefb2306bb8504bcef901a9d

Source release (checksums and signatures are available at the same 
location):

https://dist.apache.org/repos/dist/dev/cloudstack/kubernetes-provider-1.1.0/

PGP release keys (signed using 
5ED1E1122DC5E8A4A45112C2484248210EE3D884):

https://dist.apache.org/repos/dist/release/cloudstack/KEYS

For users convenience:
* docker hub - 
https://hub.docker.com/r/apache/cloudstack-kubernetes-provider/tags


* Kubernetes manifest for the rc release: 
https://github.com/apache/cloudstack-kubernetes-provider/releases/download/v1.1.0-rc1/deployment.yaml


Vote will be open for 120 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
Vishesh





From: Vishesh Jindal
Sent: Tuesday, June 18, 2024 6:36 PM
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 

Subject: [VOTE] Apache CloudStack Kubernetes Provider 1.1.0 RC1

Hi All,

I've created a 1.1.0 release (RC1) for Apache CloudStack Kubernetes 
Provider, with the following artifacts up for

a vote:

Git Branch and Commit SH:
https://github.com/apache/cloudstack-kubernetes-provider/tree/v1.1.0-rc1

Commit: 774a144876d2c875c61becab00e0487692130302

Deployment manifest:
https://github.com/apache/cloudstack-kubernetes-provider/releases/download/v1.1.0-rc1/deployment.yaml

Docker image:
apache/cloudstack-kubernetes-provider:v1.1.0-rc1

Docker image manifest digest:
sha256:38dc0a4413657b9c88cdcb28ef330e49aee6fb972a4cbc4055a0608b9f8bf7b8

You can check the changelog for the release 
here:https://github.com/apache/cloudstack-kubernetes-provider/releases/tag/v1.1.0-rc1


Vote will be open for 120 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
Vishesh


Re: [Proposal] Storage Filesystem as a First Class Feature

2024-06-19 Thread Nux

Thanks Piotr,

This is the second time virtio-fs has been mentioned and just researched 
it a bit, it looks like something really nice to have in Cloudstack, 
definitely something to look at in the future.


Nice as it is though, it has a big drawback, it's KVM-only, so for now 
we'll stick to "old school" tech that can be used in an agnostic matter.


You are more than welcome to share thoughts on the other details 
presented, perhaps pros/cons on filesystems and other gotchas you may 
have encountered yourself.


On 2024-06-19 07:04, Piotr Pisz wrote:

Hi,
We considered a similar problem in our company.
Shared storage is needed between VMs running on different networks.
NFS/CephFS is ok as long as the VM can see the source.
The best solution would be to use https://virtio-fs.gitlab.io/
Any FS would be used on the host side (e.g. NFS or CephFS) and exported 
to

the VM natively (the network problem disappears).
But you should start by introducing an appropriate mechanism on the CS 
side

(similar in operation to Manila Share from Openstack).
 So, the initiative itself is very good.

Overall, CloudStack has been heading in the right direction lately :-)

Best regards,
Piotr


-Original Message-----
From: Nux 
Sent: Wednesday, June 19, 2024 12:59 AM
To: dev@cloudstack.apache.org; Users 
Subject: Re: [Proposal] Storage Filesystem as a First Class Feature

Hi, I'd like to draw the attention to some of the more operational 
aspects

of this feature, mainly the storage appliance internals and UI.

So long story short, I've discussed with Abhisar and others and we'll 
be
deploying a VM based on the Cloudstack Debian systemvm template which 
will

export NFS v3/4 for user VMs to consume.

Below are some of the more finer details, please have a read if you are
interested in this feature and feel free to comment and make 
suggestions.


1 - The appliance will only have a single export, that export will be a
single disk (data volume). Keep it simple.
2 - GPT partition table and a single partition, filesystem probably XFS
and/or customisable - something stock Debian supports, simple and 
boring

stuff.
3 - NFS export should be simple, we can standardise on a path name eg 
/nfs

or /fileshare and it will be identical on all appliances.
4 - Starting specs: 2 cores, 4 GB RAM - should be OK for a small NFS 
server,

the appliance can be upgraded to bigger offerings.
5 - Disk offering should be flagged accordingly, the disk offering will 
have

a flag/checkbox for "storage appliance" use.
6 - This appliance will not be a system VM, it will be a "blackbox", 
but the

approach will be similar here to CKS.
7 - Security model: by default we export to * (all hosts) into a single
network - for isolated networks - in SG zones we need to play with 
security
groups & a global setting for dumb shared networks (without SG) because 
of

security implications - requires further discussion.
8 - We export with default, best practices NFS options - anything 
against

no_root_squash?
9 - Explore exporting the file share via multiple protocols - sftp, 
tftp,
smb, nfs, http(s)? - The issue here is authentication becomes a 
problem,

also user permissions will get messy and possibly conflict with
no_root_squash, in fact might require an all_squash and everything 
mapped to
a single user that will be then also used for all those other services. 
Also

logging will become necessary. Thoughts?
10 - UI details, but this will probably show up in the Storage section
somehow.
11 - Display free/used space, create alerts for full disk etc for this
appliance.
12 - Formatting and setting up to be done by an internal agent, 
specifics

are sent via the kernel cmd line of the VM, similar to how we configure
system VMs.

What do you folks think of these points and have I missed anything 
crucial?




On 2024-06-04 05:04, Abhisar Sinha wrote:

Hi,

I would like to propose supporting storage filesystem as a first-class
feature in Cloudstack.
The File Share can be associated with one or more guest networks or 
vpc

tiers and can be used by any VM on the network in a shared manner. It
is designed to be resizable and highly available. This feature can
later be used as integration endpoints with the CSI driver, go-sdk,
Terraform, Ansible and others.

The draft functional spec is here :


https://cwiki.apache.org/confluence/display/CLOUDSTACK/Storage+Filesystem+as
+a+First+Class+Feature


Looking forward to your comments and suggestions.

Thanks,
Abhisar


Re: [Proposal] Storage Filesystem as a First Class Feature

2024-06-18 Thread Nux
Hi, I'd like to draw the attention to some of the more operational 
aspects of this feature, mainly the storage appliance internals and UI.


So long story short, I've discussed with Abhisar and others and we'll be 
deploying a VM based on the Cloudstack Debian systemvm template which 
will export NFS v3/4 for user VMs to consume.


Below are some of the more finer details, please have a read if you are 
interested in this feature and feel free to comment and make 
suggestions.


1 - The appliance will only have a single export, that export will be a 
single disk (data volume). Keep it simple.
2 - GPT partition table and a single partition, filesystem probably XFS 
and/or customisable - something stock Debian supports, simple and boring 
stuff.
3 - NFS export should be simple, we can standardise on a path name eg 
/nfs or /fileshare and it will be identical on all appliances.
4 - Starting specs: 2 cores, 4 GB RAM - should be OK for a small NFS 
server, the appliance can be upgraded to bigger offerings.
5 - Disk offering should be flagged accordingly, the disk offering will 
have a flag/checkbox for "storage appliance" use.
6 - This appliance will not be a system VM, it will be a "blackbox", but 
the approach will be similar here to CKS.
7 - Security model: by default we export to * (all hosts) into a single 
network - for isolated networks - in SG zones we need to play with 
security groups & a global setting for dumb shared networks (without SG) 
because of security implications - requires further discussion.
8 - We export with default, best practices NFS options - anything 
against no_root_squash?
9 - Explore exporting the file share via multiple protocols - sftp, 
tftp, smb, nfs, http(s)? - The issue here is authentication becomes a 
problem, also user permissions will get messy and possibly conflict with 
no_root_squash, in fact might require an all_squash and everything 
mapped to a single user that will be then also used for all those other 
services. Also logging will become necessary. Thoughts?
10 - UI details, but this will probably show up in the Storage section 
somehow.
11 - Display free/used space, create alerts for full disk etc for this 
appliance.
12 - Formatting and setting up to be done by an internal agent, 
specifics are sent via the kernel cmd line of the VM, similar to how we 
configure system VMs.


What do you folks think of these points and have I missed anything 
crucial?




On 2024-06-04 05:04, Abhisar Sinha wrote:

Hi,

I would like to propose supporting storage filesystem as a first-class 
feature in Cloudstack.
The File Share can be associated with one or more guest networks or vpc 
tiers and can be used by any VM on the network in a shared manner. It 
is designed to be resizable and highly available. This feature can 
later be used as integration endpoints with the CSI driver, go-sdk, 
Terraform, Ansible and others.


The draft functional spec is here : 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Storage+Filesystem+as+a+First+Class+Feature


Looking forward to your comments and suggestions.

Thanks,
Abhisar


Re: [VOTE] Apache CloudStack 4.18.2.0 RC2

2024-04-12 Thread Nux

+1 (binding) on basic VM/storage/network lifecycle ops.

Thanks Joao

On 2024-04-12 19:56, Bryan Lima wrote:

+1

I manually tested some basic functionalities with the KVM hypervisor 
and Ubuntu 20.04 LTS:


 * VM deploy;
 * Cold and live migration with and without storage migration, NFS to
   iSCSI (SharedMountPoint) and vice-versa;
 * Network management, firewall, egress/ingress rules, and operations
   with public IP addresses;
 * Checked connectivity and (lack of) between VMs considering the
   network rules applied;
 * Creating and reverting VM and volume snapshots.

Best regards,
Bryan

On 12/04/2024 08:52, Daan Hoogland wrote:

+1 binding
I checked the hashes alright and the log of commit/tag (Note this last
check is based on the recent TZ issues to make sure nothing slipped
through). Other than that trusting on the testing I was involved in
over the last month or so.

On Fri, Apr 12, 2024 at 1:37 PM João Jandre  wrote:

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: New PMC member: Slavka Peleva

2024-04-11 Thread Nux

Congrats Slavka! :)


On 2024-04-11 08:25, Sina Kashipazha wrote:

Congratulations Slavka!

On Thu, Apr 11, 2024 at 08:18, Abhishek Kumar
 wrote:


Congratulations Slavka!


From: Ivet Petrova 
Sent: 10 April 2024 16:41
To: us...@cloudstack.apache.org ; dev

Subject: Fwd: New PMC member: Slavka Peleva

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,


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

2024-04-08 Thread Nux

+1 binding

On 2024-04-08 10:27, Daan Hoogland wrote:

I was pointed out that I did not formally vote in this mai:
+1 (binding)

On Fri, Apr 5, 2024 at 1:02 PM Daan  wrote:


Kiran, the release looks good, the format of the hashes is a bit off 
but on manual inspection they seem ok. I created a PR to correct thsi 
for next time : 
https://github.com/apache/cloudstack-terraform-provider/pull/108

I don't think that needs to block this RC

On 2024/04/04 06:30:22 Kiran Chavala wrote:
> Hi All,
>
> Reminder – terraform 0.5.0  is up for testing and voting.
>
> Regards.
> Kiran
>
> From: Rohit Yadav 
> Date: Wednesday, 3 April 2024 at 9:43 AM
> To: dev@cloudstack.apache.org , 
us...@cloudstack.apache.org 
> Subject: Re: [VOTE] Release Apache CloudStack Terraform Provider v0.5.0
> +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: [VOTE] Release Apache CloudStack CloudMonkey 6.4.0 - RC1

2024-03-27 Thread Nux

+1 (binding) based on the usual operations.

On 2024-03-27 09:39, Harikrishna Patnala wrote:

+1 Binding

Verified the checksums of the binaries and tried my usual operations of 
adding host, templates, deploying instances and few more and those 
seems fine.


Thank you everyone involved here.

Regards,
Harikrishna

From: Boris Stoyanov 
Date: Wednesday, 27 March 2024 at 1:55 PM
To: dev@cloudstack.apache.org , users 


Subject: Re: [VOTE] Release Apache CloudStack CloudMonkey 6.4.0 - RC1
+1 Binding,

I’ve installed the client locally and did some ops around, listing 
creating and updating resources. I could not find any issues.


Bobby.

From: Rohit Yadav 
Date: Thursday, 21 March 2024 at 12:39
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.


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

2024-03-21 Thread Nux

Thanks Rohit for you work this year and congratulations, Daniel!!!


On 2024-03-21 13:41, Rohit Yadav wrote:

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


Re: [PROPOSE] ACS 4.18.2.0

2024-03-21 Thread Nux

Hi Joao,

AFAIK there is only one issue to be patched properly which is in 
progress and nearly done, after which we can go ahead.


On 2024-03-20 19:14, João Jandre Paraquetti wrote:

Hi Wei, all,

Last week Wei said that there were a number of security issues that 
should be addressed before the first 4.18.2.0 RC, and thus, the same 
was delayed by a week; after that announcement, there were a few PRs 
fixing security issues on 4.18; most have been merged already, and only 
one critical PR remains open.


After the last critical PR is merged, may we proceed with the release 
process, or is there still any security issue that should be addressed?


Best Regards,
João Jandre

On 3/13/24 14:35, João Jandre Paraquetti wrote:

Hi Wei, all,

Considering that there are some security issues, we can postpone the 
4.18.2.0 release for another week. We will have two weeks before the 
first RC cut. Would that be enough time to solve all concerns?


I'd rather not postpone the release too much or it might affect the 
next ones (4.19.1.0 and 4.20.0.0).


Best regards,

João Jandre

On 3/12/24 09:40, Wei ZHOU wrote:

Hi João,

Unfortunately yes, there are SOME other security issues. The PMC is
working on the fixes.

I suggest we postpone the 4.18.2.0 release, otherwise we most likely
will have a 4.18.2.1 release.


-Wei

On Tue, Mar 12, 2024 at 1:21 PM João Jandre Paraquetti
 wrote:

Hi Wei,

Are you referring to #8729? If so, it was marked as critical (a few
minutes ago); therefore, as I announced yesterday: "From now onward, 
we
will only accept critical/blocker issues or any stabilization fixes" 
we
are still accepting fixes for critical/blocker issues, and we will 
not
release the RC until #8729 is fixed; same for #8745. Thus, we can 
keep
the freeze anyway. Or is there other security issues that I'm 
missing?


Best regards,
João Jandre

On 3/12/24 08:45, Wei ZHOU wrote:

Hi João,

As you might know, we/community are working on some security 
issues.

Please hold on.

-Wei

On Mon, Mar 11, 2024 at 7:19 PM João Jandre Paraquetti
 wrote:

Hi all,

I would like to announce the code freeze of the 4.18 branch now.
   From now onward, we will only accept critical/blocker issues or 
any
stabilization fixes. We have 70 open items in the 4.18.2.0 
milestone [1]

at the moment. Most of them will be moved to the next milestone.
Currently, there is one critical issue [1]. Which has an open PR 
to fix
the same. I count on your support on working towards cutting RC1 
in the

coming week.

Regards,
João Jandre

[1] https://github.com/apache/cloudstack/milestone/29
[2] https://github.com/apache/cloudstack/issues/8745

On 2/8/24 16:06, João Jandre Paraquetti wrote:

Hi, Rohit, all

I don't see any critical problems that should be addressed ASAP 
on the
4.18 branch; therefore, there should be no problem with 
postponing
4.18.2 a little bit. We still have several issues targeted at 
4.18.2

that have yet to be addressed, so a couple more weeks before the
freeze could be good.

Yes, I still want to be the RM for 4.18.2. I triaged all the 
issues a
couple of weeks ago and removed/added some issues to the 
milestone as
I deemed necessary, but as Rohit said, if anyone has any 
issues/PRs

they want in 4.18.2, please ping me so we can discuss/address any
concerns.

That being said, here's the updated schedule I propose:

- Until the second week of March: accept bug fixes and minor
improvements;
- Third week of March: accept only blocker and critical bug 
fixes,

aiming to stabilize the branch;
- End of March: start cutting RCs, vote, and finish release work.

Best regards,

João Jandre

On 2/8/24 03:22, Rohit Yadav wrote:

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 

Re: Re-Introduction

2024-03-18 Thread Nux

Welcome back, Sina.

Is ComplianceWise a Cloudstack user btw?

On 2024-03-17 21:10, Sina Kashipazha wrote:

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: new committer: Vishesh Jindal (vishesh)

2024-02-27 Thread Nux

Congrats & well deserved!

On 2024-02-26 14:05, Daan Hoogland wrote:

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.


Re: [VOTE] next version 20 instead of 4.20

2024-02-19 Thread Nux

+1

On 2024-02-19 15:09, Andrija Panic wrote:

+1

On Mon, 19 Feb 2024 at 13:50, Daan Hoogland  
wrote:



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: Discussion: CloudStack upgrade to JRE17 and Debian12/python3

2024-02-08 Thread Nux

+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 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: new website is life

2024-02-07 Thread Nux

Kudos to all involved!
Really nice and fancy.

On 2024-02-07 08:22, Daan Hoogland wrote:

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

thanks for any feedback


Re: [ANNOUNCEMENT] Apache CloudStack 4.19.0.0 LTS Release

2024-02-06 Thread Nux
Amazing, well done Abhishek for releasing this and all involved for 
contributing all the nice testing and features!



On 2024-02-06 11:36, Abhishek Kumar wrote:
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: [VOTE] Apache CloudStack 4.19.0.0 RC4

2024-01-31 Thread Nux
+1 (binding) based on a series of tests I've done with Advanced Zones 
and VMWare.



On 2024-01-31 17:10, Nicolas Vazquez wrote:

+1 (binding)

Repeated tests performed on previous RCs around Vmware to KVM migration 
and KVM import/export


Regards,
Nicolas Vazquez


From: Rohit Yadav 
Date: Tuesday, 30 January 2024 at 09:37
To: users , dev@cloudstack.apache.org 


Subject: Re: [VOTE] Apache CloudStack 4.19.0.0 RC4
+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


Re: Introduction and Greetings

2024-01-31 Thread Nux

Welcome! :)

On 2024-01-29 15:04, Abhisar Sinha wrote:

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: CentOS 7 is reaching EOL

2024-01-23 Thread Nux

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: [PROPOSAL] version naming : drop the 4.

2024-01-23 Thread Nux

An interesting proposition, I like it.
It would also relieve us from having to come up with any over-the-top 
feature or change for a major version change.


On 2024-01-23 14:49, Wido den Hollander wrote:
We could look at Ubuntu, and other projects, and call it 2025.01 if we 
release it in Jan 2025.


A great post on the website, mailinglists and social media could 
explain the change in versioning, but that the code doesn't change that 
much.


Project has matured, etc, etc.


Re: CentOS 7 is reaching EOL

2024-01-23 Thread Nux
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: [PROPOSAL] version naming : drop the 4.

2024-01-22 Thread Nux
Then with this kind of thinking we'll need a truly monumental 
change/features to warrant a "v5".


On 2024-01-22 11:17, Wei ZHOU wrote:

+1 with 20.0

5.0 sounds like a leap with lots of significant changes. Unfortunately 
it

has not been discussed what needs to be done.
20.0 (or 24.0) looks better.

Wei

On Mon, 22 Jan 2024 at 12:01, Daan Hoogland  
wrote:



João,
I think we should not consider 5.0, but go to 20,0 that is more in
line with what we've actually been doing (semantic versioning from the
second digit)

On Mon, Jan 22, 2024 at 11:53 AM Nux  wrote:
>
> LGTM!
>
> On 2024-01-19 19:19, João Jandre Paraquetti wrote:
> > Hi all,
> >
> > I agree that our current versioning schema doesn't make much sense, as
> > "minors" introduce pretty big features; even backward incompatibilities
> > are introduced in minor versions sometimes.
> >
> > As the current plan is to have 4.20 by June, I think we should stick to
> > it and still have the next "minor", and make it the last minor version
> > of the major 4. After so much time in the same major version, we should
> > plan something relevant before changing it, and June 2024 is a bit of a
> > tight schedule for that.
> >
> > I think that we should plan to move to version 5.0.0, we could set the
> > release date to the end of 2024 or the start (January) of 2025; by
> > doing that, we have plenty of time for planning and developing amazing
> > features for version 5, while also preparing a cleanup of our current
> > APIs. For instance, we are working on the following major developments:
> > KVM differential snapshots/backups without needing extra software;
> > theme management system (white label portal for ACS); native
> > snapshot/backup for VMware (without needing Veeam) to make it similar
> > to what ACS does with XenServer and KVM; Operators backup (which are
> > different from end-user backups); and many other items.
> >
> > What do you guys think?
> >
> > Best regards,
> > João Jandre.
> >
> > On 1/19/24 10:39, Daan Hoogland wrote:
> >> devs, PMC,
> >>
> >> as we are closing in on 4.19 I want to propose that we drop the 4. in
> >> our versioning scheme. We've been discussing 5 but no real initiatives
> >> have been taken. Nowadays big features go into our "minor"
> >> dot-releases. In my opinion this warrants promoting those version to
> >> the status of major and dropping the 4..
> >>
> >> technically this won't be an issue as 20 > 4 and out upgrade scheme
> >> supports a step like that.
> >>
> >> any thoughts?
> >>



--
Daan



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

2024-01-22 Thread Nux

LGTM!

On 2024-01-19 19:19, João Jandre Paraquetti wrote:

Hi all,

I agree that our current versioning schema doesn't make much sense, as 
"minors" introduce pretty big features; even backward incompatibilities 
are introduced in minor versions sometimes.


As the current plan is to have 4.20 by June, I think we should stick to 
it and still have the next "minor", and make it the last minor version 
of the major 4. After so much time in the same major version, we should 
plan something relevant before changing it, and June 2024 is a bit of a 
tight schedule for that.


I think that we should plan to move to version 5.0.0, we could set the 
release date to the end of 2024 or the start (January) of 2025; by 
doing that, we have plenty of time for planning and developing amazing 
features for version 5, while also preparing a cleanup of our current 
APIs. For instance, we are working on the following major developments: 
KVM differential snapshots/backups without needing extra software; 
theme management system (white label portal for ACS); native 
snapshot/backup for VMware (without needing Veeam) to make it similar 
to what ACS does with XenServer and KVM; Operators backup (which are 
different from end-user backups); and many other items.


What do you guys think?

Best regards,
João Jandre.

On 1/19/24 10:39, Daan Hoogland wrote:

devs, PMC,

as we are closing in on 4.19 I want to propose that we drop the 4. in
our versioning scheme. We've been discussing 5 but no real initiatives
have been taken. Nowadays big features go into our "minor"
dot-releases. In my opinion this warrants promoting those version to
the status of major and dropping the 4..

technically this won't be an issue as 20 > 4 and out upgrade scheme
supports a step like that.

any thoughts?



Re: new website design

2024-01-22 Thread 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: new PMC member Harikrishna Patnala

2024-01-15 Thread Nux

Congrats Harikrishna, well deserved!



On 2024-01-15 09:25, Daan Hoogland wrote:

users and dev,

The PMC have invited Harikrishna to join their ranks and he has
gracefully accepted. Please join me in congratulating Hari.


New committer: Alexandre Mattioli

2024-01-10 Thread Nux

All,

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

Alex has been instrumental in many features present today in Cloudstack, 
with a focus on networking and VMWare:

- IPv6 static routing
- Edge Zones
- Autoscaling with VR
- VNF appliances
- VMWare NSX support
- Tungsten Fabric / OpenSDN
- Backup & recovery framework
- VLAN trunking and security policies in ESX
and so on.


Please join me in congratulating Alex!



Re: [VOTE] Apache CloudStack 4.19.0.0 RC1

2023-12-22 Thread Nux

That's a nice Christmas gift, Abhishek, thanks!

I'll be testing after the new year.



On 2023-12-22 13:48, Abhishek Kumar wrote:

Hi All,

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

a vote:

Git Branch and Commit SH:
https://github.com/apache/cloudstack/tree/4.19.0.0-RC20231222T1711
Commit: 92c0fc8fc25c916a7f3c7875d924b2d14d437501

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-RC1/

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/

Vote will be open for 120 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)

Happy Christmas everyone!

@Devs - sorry the previous email wasn't copied to the user mailing list
correctly.

Regards,
Abhishek





Re: Happy Holidays!

2023-12-22 Thread Nux

Happy holidays, Ivet and all!

On 2023-12-21 13:28, Ivet Petrova wrote:

Dear community members and fellow CloudStack friends,

I want to wish you all a great holiday season, lots of great times
with your beloved ones, lots of presents and great time.
Thank you all, who are contributing to the community, who participated
at events, who supported all the community marketing initiatives!
We are a great community, and I am sure next year will be even more
successful for us as a community.

Happy Holidays,
Ivet




Re: new committer: João Jandre Paraquetti

2023-12-18 Thread Nux

Welcome aboard, João! :-)


On 2023-12-18 12:46, Daan Hoogland wrote:

community,
The PMC have invited João Jandre Paraquetti to join the project as a
committer and the invitation was gratefully accepted.
Please join me in welcoming João.
Congratulations João,


Re: Migrate from VMWare to Cloudstack/KVM

2023-12-15 Thread Nux

Hi Swen,

AFAIK nothing new on that front, but end of year is usually a bit slower 
time.
I expect this and other features will receive more attention in the new 
year.


Regards,
Lucian

On 2023-12-15 14:05, m...@swen.io wrote:

Hi all,



at CCC 2023 there were several talks about migrating instances from 
VMWare
to CS/KVM using virt-v2v. Also Olivier Lambert from Vates did a talk on 
how

XOA is doing migrations.

As far as I remember XOA is able to perform a migration significant 
faster
as virt-v2v and there was a discussion to look into the open source 
code of

XOA to see if CS can implement this migration path.



I want kindly ask if there is some progress regarding this? I see this 
as a

key feature for CS in the future to get as much VMWare installations
migrated to CS/KVM. Sadly we do not have any development capacities, 
but we

can provide help and a budget to get started.

Would that help?



Cu Swen


Re: new committer Vladimir Petrov

2023-12-12 Thread Nux

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: [PROPOSE] ACS 4.18.2.0

2023-12-10 Thread Nux
+1
Good call and good luck, João! 

On 10 December 2023 09:41:27 GMT, Daan Hoogland  wrote:
>+1 i like your proposal and support you João, Let us know what you need.
>
>On Sat, Dec 9, 2023 at 9:23 PM 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
>>
>>
>>
>>
>
>
>-- 
>Daan
>


Re: [DISCUSS] Adopting Github Discusssions Users Forum

2023-12-05 Thread Nux
Hey Rohit,

The argument applies, indeed, but it's too late for those... Isn't it? 



On 5 December 2023 14:23:53 GMT, Rohit Yadav  wrote:
>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.
>
> 
>


Re: [VOTE] Adopt Github Discusssions as Users Forum

2023-12-04 Thread Nux

-0 - I have voiced my concerns already.


On 2023-12-04 08:01, Rohit Yadav wrote:

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: new committer Bryan Lima

2023-11-30 Thread Nux

Congratulations, Bryan!


On 2023-11-30 09:07, Daan Hoogland wrote:

All,

The Project Management Committee (PMC) for Apache CloudStack
has invited Bryan Lima to become a PMC member and we are pleased
to announce that they have accepted.

Bryan has contributed himself and assisted in reviewing and testing
the work of others. He has shown to be responsive, constructive and
pleasant to work with.

please join me in congratulating Bryan


Re: [DISCUSS] Adopting Github Discusssions Users Forum

2023-11-28 Thread Nux
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.


Re: Can't upload ova file format

2023-11-06 Thread Nux
Try "qemu-img convert -p VineetVM-disk1.vmdk-O qcow2 VineetVM-disk1.img" 
but judging by those errors, the vmdk may have issues (corruption).




On 2023-11-05 19:58, Technology rss wrote:

Thank you,
I am trying 3 way convert but always failed. have any option for 
success

convert ?

root@ubuntu:~# qemu-img convert -O qcow2 VineetVM-disk1.vmdk
VineetVM-disk1.img
qemu-img: error while reading at byte 9529458688: Invalid argument

root@ubuntu:~# qemu-img convert -f vmdk -O raw  VineetVM-disk1.vmdk
VineetVM-disk1.raw
qemu-img: error while reading at byte 9529458688: Invalid argument

root@ubuntu:~# qemu-img convert -O qcow2 VineetVM-disk1.vmdk
VineetVM-disk1.qcow2
qemu-img: error while reading at byte 9529458688: Invalid argument


--


*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


On Sun, Nov 5, 2023 at 10:52 PM Rohit Yadav 
wrote:


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






Re: [DISCUSS] New benchmarking tool

2023-11-02 Thread Nux

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.


Re: Can I create 500 vm

2023-10-09 Thread Nux

Hello,

What kind of zone?

Seems right at first glance, but zone details are important.
In a security zone or basic zone it should work no problems, in an 
advanced zone it will depend on how many networks (and virtual routers) 
you want to deploy.


On 2023-10-09 19:17, Technology rss wrote:

Hi,
My network is 172.22.0.0/22

Which ip range for POD and Guest?

I needed create 500 vm on my network.

For PoD
172.22.0.2 to 172.22.1.254

For Guest
172.22.2.1 to 172.22.3.254

My setup is right or wrong?

Thanks.


Re: GSOC 2023 Results

2023-09-12 Thread Nux

Well done Ayush, thank you for your work!
Good job, Nicolas, as well!

Regards

On 2023-09-12 15:10, Nicolas Vazquez wrote:

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: Multicast traffic problem

2023-09-12 Thread Nux

Please do it yourself, it's not hard. :)


On 2023-09-12 10:12, Technology Mail wrote:

Please open this issue if possible and support to me for this.

My environment is Almalinux8, and ACS is latest.

Please

---
Thanks.

On 9/12/2023 2:42 PM, Nux wrote:

I think only icmp, tcp and udp are supported in the security groups.
Other traffic such as igmp (multicast) or gre is not supported.. It'd 
be handy if it did though, maybe open a github issue?


Regards

On 2023-09-12 09:08, Technology Mail wrote:

Hello,

I want multicast traffic enable vm to vm, How to config it? have any 
global config for this?


My security group is allow all network: 0.0.0.0/0 (Ingress Rule & 
Egress rule)


Thank you!

-- *Thanks & Regards.*

*Support Admin*



*Facebook <https://www.facebook.com/TechnologyRSS> | Twitter 
<https://twitter.com/technologyrss1> | YouTube 
<https://www.youtube.com/channel/UCBq7qGqFEUe6ObVHMuxudTw> | LinkedIn 
<https://www.linkedin.com/company/technologyrss/>*


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

Dhaka-1217, Bangladesh

*Mob :* +88 01716915504

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

*Web :* www.technologyrss.com

--

*Thanks & Regards.*

*Support Admin*



*Facebook <https://www.facebook.com/TechnologyRSS> | Twitter 
<https://twitter.com/technologyrss1> | YouTube 
<https://www.youtube.com/channel/UCBq7qGqFEUe6ObVHMuxudTw> | LinkedIn 
<https://www.linkedin.com/company/technologyrss/>*


*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: Multicast traffic problem

2023-09-12 Thread Nux

I think only icmp, tcp and udp are supported in the security groups.
Other traffic such as igmp (multicast) or gre is not supported.. It'd be 
handy if it did though, maybe open a github issue?


Regards

On 2023-09-12 09:08, Technology Mail wrote:

Hello,

I want multicast traffic enable vm to vm, How to config it? have any 
global config for this?


My security group is allow all network: 0.0.0.0/0 (Ingress Rule & 
Egress rule)


Thank you!

--

*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: [Proposal] KVM ingestion in CloudStack

2023-09-11 Thread Nux

That sounds amazing, Kishan!
Looking forward to progress on these.

Thank you

On 2023-09-11 10:17, Kishan Kavala wrote:

Hi,
CloudStack supports import/export of unmanaged instances for VMware. 
Similar feature for KVM is WIP: 
https://github.com/apache/cloudstack/pull/7712
Support for migrating instances from VMware to KVM is also WIP: 
https://github.com/apache/cloudstack/pull/7881


To enhance KVM import capabilities further, I would like to add support 
for importing  external KVM instances. External KVM instances can 
imported from non-CloudStack orchestration engines or from a standalone 
KVM host. Initial implementation will support import of libvirt based 
instances which are in stopped state (Cold Migration). Later phases can 
support Live Migration and non-libvirt based. instances (e.g. Proxmox).


regards,
Kishan


Re: [VOTE] Apache CloudStack 4.18.1.0 (RC3)

2023-09-07 Thread Nux
+1 (binding) from me based on previous testing and testing the last 
minute local storage bug.


Good job, Wei!


On 2023-09-07 09: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)

2023-09-06 Thread Nux
Thanks Wei, that's unfortunate, but hey, good thing it got caught in 
time.


Regards

On 2023-09-06 09:19, Wei ZHOU wrote:

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)

2023-09-05 Thread Nux
+1 (binding) from me based on network and storage related tests with 
both Advanced Zones (with KVM, Xen and VMware) as well as tests on 
Security Groups zones with KVM on EL8.


Regards

On 2023-09-05 13:23, Wei ZHOU wrote:

+1 (binding)

Tested the upgrade from 4.16.1, 4.17.2 and 4.18.0, checked guest OS 
mappings
Manually tested vm operations with various OSes: rocky8, alma8, 
ubuntu22,

vmware8.0c
Kicked smoke tests with various OSes: centos7, rocky8, ubuntu22,
vmware70u3, vmware80. All look ok, except 2 test failures with CKS 
which we

have seen in some PRs.

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

2023-09-04 Thread Nux

Top job!

PS: I know technically we cover this by invoking "-R" in the docs 
example, but do you think the issue warrants dropping few words in there 
to underline the issue? Something like "do note the -R switch which 
backs up the MySQL database routines"


On 2023-09-04 15:22, Rohit Yadav wrote:
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)

2023-09-04 Thread Nux

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: [DISCUSS] New Design for the Apache CloudStack Website

2023-09-01 Thread Nux

Hi Ivet,

Looks nice and trendy, thanks for the effort!

Regards

On 2023-08-30 14:34, Ivet Petrova wrote:

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 (RC2)

2023-09-01 Thread Nux

Thanks Wei!

Let the testing begin.

On 2023-09-01 08:40, Wei ZHOU wrote:

Hi all,

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

convenience.

Kind regards
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: new PMC member: Daniel Salvador

2023-08-29 Thread Nux

Congrats, Daniel and well deserved, too!

On 2023-08-29 09:51, Slavka Peleva wrote:

Congratulations Daniel!

On Sun, Aug 27, 2023 at 3:55 PM Sina Kashipazha
 wrote:



Congratulations Daniel!




--- Original Message ---
On Saturday, August 26th, 2023 at 2:31 AM, Nicolas Vazquez <
nicolas.vazq...@shapeblue.com> wrote:


>

>

> Congratulations Daniel!
>

> Regards,
> Nicolas Vazquez
> 
> From: Daman Arora damans...@gmail.com
>

> Sent: Friday, August 25, 2023 10:30:38 AM
> To: dev@cloudstack.apache.org dev@cloudstack.apache.org
>

> Subject: Re: new PMC member: Daniel Salvador
>

> Congrats Daniel!
>

> Regards,
> Damanpreet Arora
> 613-291-7558
>

>

> On Fri, 25 Aug 2023 at 09:28, Pearl d'Silva pearl.dsi...@shapeblue.com
>

> wrote:
>

> > Congratulations Daniel!
> > 
> > From: Wei ZHOU ustcweiz...@gmail.com
> > Sent: August 25, 2023 8:58 AM
> > To: dev@cloudstack.apache.org dev@cloudstack.apache.org
> > Subject: Re: new PMC member: Daniel Salvador
> >

> > Congratulations Daniel !
> >

> > -Wei
>

>

>

>

> > On Fri, 25 Aug 2023 at 12:56, Daan Hoogland d...@apache.org 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

2023-08-29 Thread Nux

Congrats, Sina and well deserved!


On 2023-08-29 09:51, Slavka Peleva wrote:

Congratulations Sina!

On Sat, Aug 26, 2023 at 6:51 PM Sina Kashipazha
 wrote:



Thanks everyone, I can't wait to merge my first PR :-)



--- Original Message ---
On Saturday, August 26th, 2023 at 2:30 AM, Nicolas Vazquez <
nicolas.vazq...@shapeblue.com> wrote:


>

>

> Congratulations Sina!
>

> Regards,
> Nicolas Vazquez
> 
> From: Daman Arora damans...@gmail.com
>

> Sent: Friday, August 25, 2023 10:30:19 AM
> To: dev@cloudstack.apache.org dev@cloudstack.apache.org
>

> Subject: Re: new committer: Sina Kashipazha
>

> Congrats Sina!
>

> Regards,
> Damanpreet Arora
> 613-291-7558
>

>

> On Fri, 25 Aug 2023 at 09:28, Pearl d'Silva pearl.dsi...@shapeblue.com
>

> wrote:
>

> > Congratulations Sina!
> > 
> > From: Wei ZHOU ustcweiz...@gmail.com
> > Sent: August 25, 2023 8:58 AM
> > To: dev@cloudstack.apache.org dev@cloudstack.apache.org
> > Subject: Re: new committer: Sina Kashipazha
> >

> > Congratulations Sina !
> >

> > -Wei
>

>

>

>

> > On Fri, 25 Aug 2023 at 12:53, Daan Hoogland d...@apache.org 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: [Consultation] Remove DB HA feature (db.ha.enabled)

2023-08-29 Thread Nux

+1, looking forward to a PR I can test then.

Regards

On 2023-08-23 11:59, Rohit Yadav wrote:

Thanks João, Daniel,

I see João's PR - I'm not keen on getting the mysql-ha plugin removed 
if it can be improved/fixed. What users complain about is when it 
doesn't work or the documentation isn't clear about how to use it (or 
in fact have any MySQL HA plan for use with CloudStack).



Regards.


From: João Jandre Paraquetti 
Sent: Wednesday, August 23, 2023 01:26
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 

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

Sure, Daniel

PR #7895 is currently in draft as we need to do some more tests.
However, the intention is to enable users to configure the DB 
connection
URI directly through `db.properties` file. These are the tests that 
have

been done so far with ACS without this PR changeset:

Using the current version in a setup with MariaDB and Galera, with a
cluster size of 3 and the following configuration on the db.properties 
file:

```
# High Availability And Cluster Properties
db.ha.enabled=true
db.ha.loadBalanceStrategy=com.cloud.utils.db.StaticStrategy
# cloud stack Database
db.cloud.replicas=192.168.201.161,192.168.201.162
db.cloud.autoReconnect=false
db.cloud.failOverReadOnly=false
db.cloud.reconnectAtTxEnd=false
db.cloud.autoReconnectForPools=true
db.cloud.secondsBeforeRetrySource=1800
db.cloud.queriesBeforeRetrySource=5000
db.cloud.initialTimeout=3600
```
When the MariaDB service stops in the main node, ACS switches to one of
the other two nodes. However, if the host is shut down, the switch 
never

occurs.

Then, we also did tests using the changes proposed in the PR, by
configuring the db.cloud.uri:

```
db.cloud.uri=jdbc:mariadb:sequential://192.168.201.160:3306,192.168.201.161:3306,192.168.201.162:3306/cloud?autoReconnect=true=517=true=sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION'=UTC

# These properties are ignored when setting the URI manually, so no 
need

to set them.

# High Availability And Cluster Properties
# db.ha.enabled=true
# db.ha.loadBalanceStrategy=com.cloud.utils.db.StaticStrategy
# cloud stack Database
# db.cloud.replicas=192.168.201.161,192.168.201.162
# db.cloud.autoReconnect=false
# db.cloud.failOverReadOnly=false
# db.cloud.reconnectAtTxEnd=false
# db.cloud.autoReconnectForPools=true
# db.cloud.secondsBeforeRetrySource=1800
# db.cloud.queriesBeforeRetrySource=5000
# db.cloud.initialTimeout=3600
```

I was able to configure and use the sequential failover mode. This way,
when the MariaDB service stops in the main node and even if the host is
shut down, ACS is able to switch to the other DBs.

There are two differences between defining the URI manually (which is
proposed with PR#7895) and the generated by ACS.
The first one is the `jdbc:mariadb`, which is the driver that makes the
connection with the DBMS, this enables usage of MariaDB URL
configurations, this driver is being introduced into ACS with PR#7895.
The second one is the usage of the `sequential` [1] failover mode, that
will try to connect to hosts in the order in which they were declared 
in
the connection URL, so the first available host is used for all 
queries,

and if one of the hosts is shut down, it will try to reconnect with the
other on the list. As this mode only connects to a single DB, the
problems referenced by Rohit are avoided. But the failover mechanism is
still in place.

Best regards,
João Jandre

[1] - https://mariadb.com/kb/en/about-mariadb-connector-j/

On 22/08/2023 16:03, Daniel Salvador wrote:

Hello Lucian and all,

I am -1 on removing the whole DB HA feature from CloudStack.

As we discussed on July[1], the current properties we have on
"db.properties" regarding DB HA are hardcoded and only address some 
MySQL

properties, which are not fully compatible with the properties for
configuring DB HA on MariaDB. It indeed has some problems; however, I 
think
we should keep the functionality and improve it, to enrich CloudStack 
and

avoid using other layers to accomplish the goals. It is good to have a
workaround, though.

João Jandre and I are already working on a solution to flexibilize the 
DB
parameters in order to allow one to configure DB HA properly when 
using
MariaDB (and also do several other configurations). João, could you 
point
to the PR that addresses the changes and share the configurations and 
tests

we have done so far?

Best regards,
Daniel Salvador (gutoveronezi)

[1] - https://lists.apache.org/thread/j0mmwy9dfr9k2kbnnjxcr2m7y8zwd34c

On Tue, Aug 22, 2023 at 12:42 PM Nux  wrote:

New adopters may not go ahead with it in production because they 
won't
get it working, unless they fix a lot of code, that would be a nice 
pull

request. :)


On 2023-08-22 16:25, K B Shiv Kumar wrote:
Well, if it is broken and it is not prominently mentioned anywhere 
new

adopters may go ahead with that on produc

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

2023-08-22 Thread Nux
New adopters may not go ahead with it in production because they won't 
get it working, unless they fix a lot of code, that would be a nice pull 
request. :)



On 2023-08-22 16:25, K B Shiv Kumar wrote:
Well, if it is broken and it is not prominently 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: [Consultation] Remove DB HA feature (db.ha.enabled)

2023-08-22 Thread Nux

Thanks for elaborating, Rohit.


On 2023-08-22 16:25, Rohit Yadav wrote:

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)

2023-08-22 Thread Nux

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: Register Now for CloudStack Collaboration Conference - First 50 get a CloudStack T-shirt

2023-08-22 Thread Nux

Do you have a picture of them?

Thanks

On 2023-08-21 13:14, Ivet Petrova wrote:

Hi all,

I am happy to announce that we have a special surprise for the early 
birds! As you know the CloudStack Collaboration Conference will happen 
on November 23-24th in Paris, France.
Now we have a special surprise for the first 50 people registered for 
the event!
Get an Apache Cloudstack branded Tshirt special edition for the 
conference in Paris.


Hurry up, we are limited in these cool t-shirts: 
https://events.hubilo.com/cloudstack-collaboration-conference-2023/register



Kind regards,


Re: [PROPOSE] ACS 4.18.1.0 release

2023-08-22 Thread Nux

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)

2023-08-22 Thread Nux
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


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

2023-08-22 Thread Nux

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: Cloudstack DB HA, do you use db.ha.enabled?

2023-07-20 Thread Nux

Cheers Simon,

I'll double check the jar is loaded in my next tests.



On 2023-07-20 22:08, Simon Weller wrote:

Lucian,

Check to see whether the mysql-ha jar is being loaded. There's a 
separate

mysql-ha package that needs to be installed.

Is this Ubuntu or rpm? I'm not sure whether the default Ubuntu builds
include the extra package. I believe the shapeblue build does though.

-Si


On Thu, Jul 20, 2023, 3:03 PM Nux  wrote:


Cheers Daniel,

Can you share any other db.ha parameters you may have tuned?
For me it didn't work out of the box as you described.

Thanks

On 2023-07-20 14:04, Daniel Salvador wrote:
> Hello Nux,
>
> Normally I set up three nodes with MariaDB and Galera cluster; then, in
> the
> "db.properties" file I mark "db.ha.enabled" as true, and I define one
> of
> the nodes as main and the other as replicas. When the main node goes
> down,
> one of the replicas takes over, and so on.
>
> The current properties we have on "db.properties" regarding DB HA are
> hard
> coded and only address some MySQL properties; which is not the perfect
> scenario for MariaDB HA. However, it provides a minimum DB HA setup. Me
> and
> other contributors are already working on a flexible solution to
> address
> other MySQL properties, and MariaDB properties as well.
>
> Best regards,
> Daniel Salvador (gutoveronezi)
>
> On Thu, Jul 20, 2023 at 7:46 AM Nux  wrote:
>
>> Hello,
>>
>> As per the subject, how do you make your DB layer HA and do you use
>> the
>> db.ha.enabled feature/setting in the Cloudstack management server
>> db.properties file?
>>
>> Cheers
>>



Re: Cloudstack DB HA, do you use db.ha.enabled?

2023-07-20 Thread Nux

Cheers Daniel,

Can you share any other db.ha parameters you may have tuned?
For me it didn't work out of the box as you described.

Thanks

On 2023-07-20 14:04, Daniel Salvador wrote:

Hello Nux,

Normally I set up three nodes with MariaDB and Galera cluster; then, in 
the
"db.properties" file I mark "db.ha.enabled" as true, and I define one 
of
the nodes as main and the other as replicas. When the main node goes 
down,

one of the replicas takes over, and so on.

The current properties we have on "db.properties" regarding DB HA are 
hard

coded and only address some MySQL properties; which is not the perfect
scenario for MariaDB HA. However, it provides a minimum DB HA setup. Me 
and
other contributors are already working on a flexible solution to 
address

other MySQL properties, and MariaDB properties as well.

Best regards,
Daniel Salvador (gutoveronezi)

On Thu, Jul 20, 2023 at 7:46 AM Nux  wrote:


Hello,

As per the subject, how do you make your DB layer HA and do you use 
the

db.ha.enabled feature/setting in the Cloudstack management server
db.properties file?

Cheers



Cloudstack DB HA, do you use db.ha.enabled?

2023-07-20 Thread Nux

Hello,

As per the subject, how do you make your DB layer HA and do you use the 
db.ha.enabled feature/setting in the Cloudstack management server 
db.properties file?


Cheers


Re: [VOTE] CloudStack Project Blog Migration

2023-05-23 Thread Nux

+1 (binding)

On 2023-05-22 11:13, Wei ZHOU wrote:

+1 (binding)

Great job @Rohit Yadav 

-Wei



On Wed, 17 May 2023 at 10:58, Rohit Yadav  wrote:


All,

The ASF-infra had announced a hard deadline [0][1] to decommission our
project’s Roller based blog [3] on the 31st May 2023.

For the blog migration, ASF-infra has exported CloudStack blog posts
from the current Roller’s database-backed infra to markdown files.
These were put together in cloudstack-www repository’s
docusauras-staging branch [2] with Docusauras used as a
static-site-generator and a GitHub Actions workflow to automate
publishing a staging site for your testing and review [4].

The staging site that migrates both the website and blog isn’t
completely ready to meet the hard deadline, so this vote is proposed
for only migrating the blog before the deadline and continue efforts
to migrate to a new website [2][4] when we're ready in the near
future.

The following is put for voting:

1. By the end of 31st May ’23, ASF-infra will decommission the project
blog at https://blogs.apache.org/cloudstack and for now we proceed
with only the blog migration before this deadline.

2. The old blog URL/pages from
https://blogs.apache.org/cloudstack/ will be
redirected to https://cloudstack.apache.org/blog/.
This will be done by the ASF-infra.

3. The blog content is copied to the "content/blog" directory of the
asf-site branch in the https://github.com/apache/cloudstack-www
repository [6], published at https://cloudstack.apache.org/blog/.

The vote will be open until we reach a lazy consensus.

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)

[0] https://markmail.org/message/o5pse33cgriebsrg
[1] https://lists.apache.org/thread/hfhzochhmqhd32tclgc47d5nk90jxmb2
[2] 
https://github.com/apache/cloudstack-www/tree/docusaurus-staging/blog

[3] https://blogs.apache.org/cloudstack/
[4] https://cloudstack.staged.apache.org/
[5] https://cloudstack.apache.org/bylaws.html
[6]
https://github.com/apache/cloudstack-www/commit/651ec3ad9a3f524a5ce1bb9d6943856f57e638e3

Regards.



Re: ACS upgrade to Log4J2 version 2.19

2023-05-02 Thread Nux

Hi Daniel and all,

With my PMC hat on, I'm +1 on implementing this PR. "The show must go 
on" as they say.


I also see no reason this should wait for 5.0, there is nothing special 
about v5 that I know of, it's just a number.


The PR is indeed quite large and it has the potential to "inconvenience" 
any release, should we postpone it.
I am a bit weary it may break some things and/or catch some users 
unprepared that may rely on log4j (v1) specifics, but at the end of the 
day it's "just" logging and any healthy open source project needs to 
make progress.


The one issue I have - as a non-coder - is that there could have been 
better comms around this issue on the mailing list, I'm not great at 
following Github developments.


My 2 pence,
Lucian



On 2023-05-01 14:27, Daniel Salvador wrote:

Abhishek,

I do not see why it would be a 5.0 change. Also, ACS 5.0 is a 
discussion
the community has been having for a long time from now and is something 
we

are too far away to achieve consensus.

The patch is important to enable further development for the log 
management
on ACS and facilitate everyone's life while coding and troubleshooting. 
If
you think it is too much work for the RM, I reiterate that I am willing 
to

be the 4.19 RM and conduct/execute all of the work.

Best regards,
Daniel Salvador (gutoveronezi)

On Mon, May 1, 2023 at 4:10 AM Abhishek Kumar  
wrote:



Great work.
Though I feel this is a 5.0 change. I agree with Wei that this would 
create
too much overhead for upcoming releases. 4.18 was pushed ahead a few 
months

and we may end up on a similar path.
Also, reload4j is still actively maintained so I don't think this is
urgent.

Regards,
Abhishek

On Fri, 28 Apr 2023 at 18:28, João Jandre Paraquetti 

>
wrote:

> In PR #7131 (https://github.com/apache/cloudstack/pull/7131) I have
> proposed to normalize ACS's loggers, and more importantly, upgrade the
> library log4j to log4j2 version 2.19.
>
> Log4j2 has a lot of features that could offer benefits to ACS:
>
>   * Async Loggers - performance similar to logging switched off
>   * Custom log levels
>   * Automatically reload its configuration upon modification without
> loosing log events during reconfigurations.
>   * Java 8-style lambda support for lazy logging (which enables methods
> to be executed only when necessary, i.e.: the right log level)
>   * Log4j 2 is garbage-free (or at least low-garbage) since version 2.6
>   * Plugin Architecture - easy to extend by building custom components
>   * Log4j 2 API is separated from the Log4j 2 implementation.
>   * Log4j 2 API supports more than just logging Strings: CharSequences,
> Objects and custom Messages. Messages allow support for interesting
> and complex constructs to be passed through the logging system and
> be efficiently manipulated. Users are free to create their own
> Message types and write custom Layouts, Filters and Lookups to
> manipulate them.
>   * Concurrency improvements: log4j2 uses java.util.concurrent libraries
> to perform locking at the lowest level possible. Log4j-1.x has known
> deadlock issues.
>   * Configuration via XML, JSON, YAML, properties configuration files or
> programmatically.
>
> In my personal experience using it in some other projects, log4j2 is
> easier to work with in general, has better performance, and is an active
> project with constant development, innovation, and security patches.
> Moreover, it is under a well known and trusted open source organization.
>
> The change proposed in PR #7131
> (https://github.com/apache/cloudstack/pull/7131) has been tested and
> validated in a lot of different scenarios by different people. We have
> already tested the logging in the management server, usage, agents, and
> system VMs; all of that using KVM and Vmware + Veeam. Most feature sets
> were tested, create/delete/update VMs, disks, cresate snapshots, user
> management and so on.
>
> The proposal has been discussed since January, 2023 in the PR
> (https://github.com/apache/cloudstack/pull/7131), but I have been
> requested to bring it to the mailing list. I would love to hear your
> opinions on it, also, any reviews to the PR would be welcome.



Re: Daan Hoogland - New ASF Member

2023-03-24 Thread Nux

Wow, congrats Daan!

On 2023-03-24 09:28, Paul Angus wrote:
It is my pleasure to announce that Daan Hoogland as been elected to 
become a

member of the ASF.

The ASF would like to recognize both his practical involvement and the 
way

in which he has interacted with others in and around the ASF.



Congratulations  Daan.









Kind regards



Paul Angus


Re: [RESULT][VOTE] Apache CloudStack 4.18.0.0

2023-03-16 Thread Nux

Cheers, Daan!

On 2023-03-15 18:32, Daan Hoogland wrote:

Hi all,

After 72 hours, the vote for CloudStack 4.18.0.0 *passes* with
5 PMC + 0 non-PMC votes.

+1 (PMC / binding)
* Nux (lucian)
* Rohit
* Simon
* Boris
* Nicolas

+1 (non binding)
None

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: [4.18][RC3][VOTE] new release candidate 4.18.0.0-RC20230311T0935

2023-03-14 Thread Nux

Thanks for the packages, Daan.

+1 from me (binding) based on testing I've done with KVM and SG zones 
(in addition to my previous testing on regular advanced zones).



On 2023-03-13 10:41, Daan Hoogland wrote:

packages are available at
https://download.cloudstack.org/testing/4.18-rc3/
and
http://packages.shapeblue.com/cloudstack/upstream/testing/4.18.0.0-RC20230311T0935/

On Sat, Mar 11, 2023 at 9:45 AM Daan Hoogland  wrote:


Hi All,

I've created a new 4.18 release candidate, with the following 
artifacts up for a vote:


Git Branch and Commit 
SH:https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.18.0.0-RC20230311T0935

Commit: 0574087284f8b646ebc41617cfd70b3a31e3ae94

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

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


Vote will be open for 72 hours. (aiming for wednesday late)

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)

As usual lately, I will work on getting some convenience packages 
ready and will follow up on this thread to link you to those.


enjoy




Re: Hello Community!!

2023-03-14 Thread Nux

Hello and welcome aboard, Jithin!

On 2023-03-14 07:57, Jithin Raju wrote:

Hi All,

I have joined ShapeBlue and looking forward to getting actively 
involved in the community. Previously I worked on the commercial fork 
of the ACS, mostly involved in technical support.


-Jithin


Re: Hello Again!

2023-03-13 Thread Nux

Welcome! :)

On 2023-03-09 10:41, Kishan Kavala wrote:

Hi,
 I've joined ShapeBlue and very happy to back with CloudStack 
community. Looking forward to working with you all.


regards,
Kishan


Re: [4.18][RELEASE] RC2 up for vote

2023-02-28 Thread Nux

+1 (binding) based on tests I've done with KVM/EL8 and VMware 7.0.


On 2023-02-24 12:10, Daan Hoogland wrote:

77961d6aa583a347b289af4cbb732b77c8be8ebe

Hi All,
It has taken some time but;

I've created a second 4.18.0.0 release candidate, with the following
artifacts up for a vote:

Git Branch and Commit
SH:https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.18.0.0-RC20230224T1301
Commit: 77961d6aa583a347b289af4cbb732b77c8be8ebe

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

PGP release keys (signed using
):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: [ANNOUNCE] Ivet Petrova has joined the PMC

2023-02-17 Thread Nux
Congratulations and thanks for all your work around promoting 
Cloudstack! :)



On 2023-02-14 16:00, Simon Weller wrote:

Hi everyone,

It gives me great pleasure to announce that Ivet has been invited to 
join

the
CloudStack PMC and she has accepted.

Please join me in congratulating Ivet!

-Simon (on behalf of the CloudStack PMC)


Re: Hello

2023-02-01 Thread Nux

Welcome, Vishesh!

On 2023-02-01 15:44, Vishesh Jindal wrote:

Hi All,

This is Vishesh. I have recently joined ShapeBlue. I am looking forward 
to contributing to the cloudstack project and working with the 
community.


Thanks!
Vishesh Jindal
vishesh.jin...@shapeblue.com


Re: GSoC 2023

2023-01-26 Thread Nux

Thanks for stepping up, Nicolas!

Regards

On 2023-01-25 16:47, Nicolas Vazquez wrote:

Hi all,

Google Summer of Code (GSoC) 2023 has already been announced and the 
timeline is available on this link: 
https://developers.google.com/open-source/gsoc/timeline. I would like 
to volunteer as the coordinator for our GSoC involvement this year if 
nobody objects.


Starting from this week, organizations can start submitting 
applications for the program. To submit your idea please create a 
GitHub issue at the official ACS repository with label “gsoc23” (such 
as: 
https://github.com/apache/cloudstack/issues?q=is%3Aopen+is%3Aissue+label%3Agsoc2023), 
we’ll later review and work with the ASF guys to make this list 
available for applications. You will also need to register as a mentor. 
To become a mentor you don’t need to be committer or PMC, just to have 
an idea and the will to support and guide a contributor developing it. 
Registering is also easy, please send an email to private@ and ask to 
be recognized as such.


You can find the general information of the program on: 
https://summerofcode.withgoogle.com/


The announcement for this year: 
https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html


There are no major changes from the last year’s program, the only 
difference is this year GSoC is accepting begginers on open source 
software development and students as contributors.


Please directly add your project idea, and of course if you have 
questions I’ll be available to help.


Regards,
Nicolas Vazquez


Re: CloudStack and Tungsten Fabric Solution Brief

2023-01-24 Thread Nux

Thanks Ivet, this is amazing!
ACS does need a new SDN story and Tungsten looks the real deal here, 
can't wait to try it!


Also cheers to EWERK and ENA for their involvement to make this happen!

Regards

On 2023-01-24 11:31, Ivet Petrova wrote:

Hi all,

I am happy to share a new solution brief we have developed together 
with the team of Tungsten Fabric: 
https://blogs.apache.org/cloudstack/entry/apache-cloudstack-and-tungsten-fabric
If you are interested to learn more for SDN and how tungsten integrates 
with CloudStack take a look.


Kind regards,


Re: [4.18][RELEASE] timeline

2023-01-06 Thread Nux

Thanks, Daan, looking good.

---
Nux
www.nux.ro

On 2023-01-03 09:39, Daan Hoogland wrote:
Happy new year to all, I wish you enjoyment wisdom health and strength 
in

your work and your private lives.

I wish to inform you of my plans for the coming weeks as a Release 
Manager:

At the moment we have
- 32 issues and
- 31 pull requests
marked for 4.18. These numbers were a bit lower end of last year and to
prevent shooting at a moving target I want to share the following.

This week, I want to create a milestone 4.18.1.0 and move any issue 
that

- reads as a bug report
- does not have someone assigned
- does not have a linked pull request
In addition I want to move to milestone 4.19.0.0, any issue that
- reads as an enhancement or a feature request
- does not have a pull request linked

In two weeks, on the 17th, I want to call a freeze on merges to main 
for

stabilization.
At the end of January, approximately on the 31st I want to release RC1.

I am open to any request for change in this schedule. There are some 
hefty
PRs out that I imagine everybody wants in, and you may have quick and 
handy

or vital fixes to add as well. Please feel free to address me on this
thread or on any DM I appear responsive on.

regards,


Re: [VOTE] Apache Cloudstack 4.17.2.0 (RC3)

2022-12-16 Thread Nux

Well done, Rohit!

---
Nux
www.nux.ro

On 2022-12-16 15:15, Rohit Yadav wrote:

Hi all,

The vote for Apache CloudStack 4.17.2.0 *passes* with
5 PMC + 2 non-PMC votes.

+1 (PMC / binding)
5 person (Boris, Lucian, Daan, Nicolas, Rohit)

+1 (non binding)
2 person (Abhishek, Vladimir)

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.


On Wed, 14 Dec 2022 at 10:56, Rohit Yadav  wrote:


All,

I've created a 4.17.2.0 release, with the following artifacts up for a
vote:

Git Branch and Commit SHA:
https://github.com/apache/cloudstack/tree/4.17.2.0-RC20221214T0522
Commit: 5b9a989ab0dd6b8f482f4d6c6ce24e1a6108002e

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

PGP release keys (signed using 
5ED1E1122DC5E8A4A45112C2484248210EE3D884):

https://dist.apache.org/repos/dist/release/cloudstack/KEYS

The vote will be open for 72 hours, until the end of 16 Dec 2022.

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)

For users' convenience, the packages from this release candidate (RC3) 
and

4.17.2 systemvmtemplates are available here:
https://download.cloudstack.org/testing/4.17.2.0-RC3/ 
(building/uploading)

https://download.cloudstack.org/systemvm/4.17/

Documentation is not officially published yet, you may refer to the
following doc PR:
https://github.com/apache/cloudstack-documentation/pull/295

The list of changes included in this minor release over 4.17.1.0 can 
be

referenced here:
https://github.com/apache/cloudstack/milestone/26?closed=1

Regards.



Re: [VOTE] Apache Cloudstack 4.17.2.0 (RC3)

2022-12-16 Thread Nux

+1 (binding)

Done loads of testing with Advanced zones (with and without SG)

---
Nux
www.nux.ro

On 2022-12-16 09:44, Boris Stoyanov wrote:

+1 (binding)

I’ve did a quick testing around main lifecycle operations of VMs,
Volumes, Networks, offerings and infra. Looks good to me.

Regards,
Bobby.

From: Rohit Yadav 
Date: Wednesday, 14 December 2022, 7:27
To: dev , users 


Subject: [VOTE] Apache Cloudstack 4.17.2.0 (RC3)
All,

I've created a 4.17.2.0 release, with the following artifacts up for a 
vote:


Git Branch and Commit SHA:
https://github.com/apache/cloudstack/tree/4.17.2.0-RC20221214T0522
Commit: 5b9a989ab0dd6b8f482f4d6c6ce24e1a6108002e

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

PGP release keys (signed using 
5ED1E1122DC5E8A4A45112C2484248210EE3D884):

https://dist.apache.org/repos/dist/release/cloudstack/KEYS

The vote will be open for 72 hours, until the end of 16 Dec 2022.

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)

For users' convenience, the packages from this release candidate (RC3) 
and

4.17.2 systemvmtemplates are available here:
https://download.cloudstack.org/testing/4.17.2.0-RC3/ 
(building/uploading)

https://download.cloudstack.org/systemvm/4.17/

Documentation is not officially published yet, you may refer to the
following doc PR:
https://github.com/apache/cloudstack-documentation/pull/295

The list of changes included in this minor release over 4.17.1.0 can be
referenced here:
https://github.com/apache/cloudstack/milestone/26?closed=1

Regards.


Re: [DISCUSS] Github Discussions for CloudStack?

2022-12-14 Thread Nux
That's a good point, it'd be nice if there was a possibility to use the 
"discussions" integrated in the mailing lists.


---
Nux
www.nux.ro

On 2022-12-14 12:22, Daniel Augusto Veronezi Salvador wrote:

Hello all,

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

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

Best regards,
Daniel Salvador (gutoveronezi)

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

All,

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


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


Several Apache projects have enabled Github Discussions [1], for 
example:

https://github.com/apache/couchdb/discussions
https://github.com/apache/apisix/discussions
https://github.com/apache/shardingsphere/discussions
https://github.com/apache/streampipes/discussions
https://github.com/apache/pulsar/discussions
https://github.com/apache/airflow/discussions
https://github.com/apache/dolphinscheduler/discussions
https://github.com/apache/inlong/discussions
https://github.com/apache/doris/discussions
https://github.com/apache/arrow-datafusion/discussions
https://github.com/apache/superset/discussions

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


Regards.




Re: VMs HA not working with Ceph

2022-12-05 Thread Nux

Great pointer, Daniel, thank you!


---
Nux
www.nux.ro

On 2022-12-05 16:26, Daniel Augusto Veronezi Salvador wrote:

Hello, Ranjit and Nux

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

Best regards,
Daniel Salvador (gutoveronezi)

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

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

Hello,

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


---
Nux
www.nux.ro

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

Hello Guys,

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

Regards,
Ranjit

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


wrote:


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

Regards Pradeep Kumar


Re: VMs HA not working with Ceph

2022-12-05 Thread Nux

Hello,

For HA to work you need to:
1 - add a service offering with "HA" box enabled
2 - you need to have some NFS storage for the heartbeat/fencing 
mechanism - you don't need to use it for VMs, but it needs to be present 
and it needs to be super reliable or hypervisors might reboot if they 
see it goes away - this behaviour can be customised if you want to (and 
know what you are doing):

https://github.com/apache/cloudstack/blob/a63b2aba7aa3948f78d280a356c550c6638a137b/scripts/vm/hypervisor/kvm/kvmheartbeat.sh#L162

HTH

---
Nux
www.nux.ro

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

Hello Guys,

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

Regards,
Ranjit

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


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

Regards Pradeep Kumar


Re: [PROPOSAL] postpone 4.18 to the new year

2022-11-01 Thread Nux

+1 postponing

---
Nux
www.nux.ro

On 2022-10-29 09:25, Daan Hoogland wrote:

Users and devs,

I announced to start the releasing by end of October [1] but I think we
have a lot of promising PRs that would really make this release 
worthwhile.

At the same time the noteworthy features that are in now are limited:



What is in:

- custom tarifs

- Prometeus exporter enhancements

- volume encryption

- console access enhancements

- custom DNS for guest networks



pending:

- ant-design upgrade #6369

- EMC networker B #6550

- clone virtual machine #5216

- keyboard shortcuts #5122

- vm deploy retry #6062

- tungsten fabric #4205

- intuitive global setting #5797



I want to therefore postpone the release till January, or at leaset 
till

after CCC. I think a release
will have much more value if we wait until some more of these are in.

regards,

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


Re: Hello!

2022-10-10 Thread Nux

Welcome! :)

---
Nux
www.nux.ro

On 2022-10-10 05:02, Rahul Agarwal wrote:

Hi All,

My name is Rahul Agarwal.I have recently joined ShapeBlue Engineering
Team as Software Engineer . I look forward
to make contributions to Apache Cloudstack and ask questions on mailing 
list .


Cheers,
Rahul Agarwal


Re: [VOTE] Apache CloudStack 4.17.1.0 (RC2)

2022-09-14 Thread Nux

+1 (binding)

---
Nux
www.nux.ro

On 2022-09-14 10:40, Abhishek Kumar wrote:

Hi All,

I've created a 4.17.1.0 release, with the following artifacts up for a 
vote:


Git Branch and Commit SH:
https://github.com/apache/cloudstack/tree/4.17.1.0-RC20220914T1258
Commit: 350ef38e1cbd001c77e6b919b8f1fedcf1bcce64

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

PGP release keys (signed using 
65518106473A09D7AF26B384A70BD2EAA74E2866):

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, the packages from this release candidate (RC2)
and 4.17.0 systemvmtemplates (there is no change in system VM template
since 4.17.0.0 release and the same 4.17.0 system VM templates can be
used) are available here:
https://download.cloudstack.org/testing/4.17.1.0-RC2/
https://download.cloudstack.org/systemvm/4.17/

Documentation is not published yet, but the following may be referenced 
for

upgrade related tests:
https://github.com/apache/cloudstack-documentation/tree/4.17/source/upgrading/upgrade

Regards,
Abhishek


Re: [VOTE] Apache CloudStack 4.17.1.0 (RC1)

2022-09-07 Thread Nux

+1 (binding) from me based on the testing I've done.

---
Nux
www.nux.ro

On 2022-09-07 13:50, Abhishek Kumar wrote:

Hi All,

I've created a 4.17.1.0 release, with the following artifacts up for a 
vote:


Git Branch and Commit SH:
https://github.com/apache/cloudstack/tree/4.17.1.0-RC20220907T1706
Commit: cf815b051d2cd0e88fda40ab1690d7b173f68fdf

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

PGP release keys (signed using 
65518106473A09D7AF26B384A70BD2EAA74E2866):

https://dist.apache.org/repos/dist/release/cloudstack/KEYS

Vote will be open for 120 hours, until 12 Sep 2022.

For sanity in tallying the vote, can PMC members please be sure to
indicate "(binding)" with their vote?

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

For users convenience, the packages from this release candidate (RC1)
and 4.17.0 systemvmtemplates (there is no change in system vm template
since 4.17.0.0 release and the same 4.17.0 system vm templates can be
used) are available here:
https://download.cloudstack.org/testing/4.17.1.0-RC1/
https://download.cloudstack.org/systemvm/4.17/

Documentation is not published yet, but the following may be referenced 
for

upgrade related tests:

https://github.com/apache/cloudstack-documentation/tree/4.17/source/upgrading/upgrade

Regards,
Abhishek
<https://github.com/apache/cloudstack-documentation/tree/4.17/source/upgrading/upgrade>


Re: Running the UI on Docker container

2022-09-07 Thread Nux
Unless you're adamant on _building_ the UI, then you could create a 
docker container with the rpm/deb instead, if that helps.



---
Nux
www.nux.ro

On 2022-09-07 08:34, Nux wrote:

Wido,

I've just run the UI standalone on a separate machine the other day,
but not on docker.
What I did was to install cloudstack-ui rpm package, then serve it
like a normal site, but proxy /client to mgmt-server:8000 like
described here:

https://github.com/apache/cloudstack/tree/main/ui#production

hth

---
Nux
www.nux.ro

On 2022-09-06 15:56, Wido den Hollander wrote:

Hi,

Anybody there running the UI outside the Management Server in a Docker
container like described here?

https://github.com/apache/cloudstack/tree/main/ui

I have a use-case for this we would like to investigate, but the build
currently fails [0].

Is this still relevant and supported?

Wido

[0]: https://github.com/apache/cloudstack/issues/6709


Re: Running the UI on Docker container

2022-09-07 Thread Nux

Wido,

I've just run the UI standalone on a separate machine the other day, but 
not on docker.
What I did was to install cloudstack-ui rpm package, then serve it like 
a normal site, but proxy /client to mgmt-server:8000 like described 
here:


https://github.com/apache/cloudstack/tree/main/ui#production

hth

---
Nux
www.nux.ro

On 2022-09-06 15:56, Wido den Hollander wrote:

Hi,

Anybody there running the UI outside the Management Server in a Docker
container like described here?

https://github.com/apache/cloudstack/tree/main/ui

I have a use-case for this we would like to investigate, but the build
currently fails [0].

Is this still relevant and supported?

Wido

[0]: https://github.com/apache/cloudstack/issues/6709


Re: Introducing Bart and Ruben

2022-08-09 Thread Nux

Welcome aboard, guys!

---
Nux
www.nux.ro

On 2022-08-08 13:43, Wido den Hollander wrote:

Hi devs,

Recently Bart and Ruben (CC) joined CLDIN (was PCextreme) as DevOps
engineers and will be working on CloudStack and start to contribute to
the project.

In the coming months they'll finding their way around in the community
and code and you should start seeing Pull Requests from them coming
in.

We'll try to make the CCC in Bulgaria later this year!

Wido


Re: [PROPOSE] CloudStack 4.17.1.0 release and RM

2022-08-03 Thread Nux

+1, thanks for volunteering Abhishek. You'll do a great job.

---
Nux
www.nux.ro

On 2022-08-02 18:37, Abhishek Kumar wrote:

Hi all,

I would like to propose and put myself forward as the release manager
for the 4.17.1.0 release. My colleague Nicolas Vazquez will support me
as the co-RM for the PR reviews/tests/merges, and others are welcome
to support as well.
We can keep the scope limited to include only bugs, critical issues
and fixes for a stable release. I see about 89 closed issues/PRs
already on the 4.17.1.0 milestone[1] and some 24 items are remaining.

I propose the following timeline, aiming to cut the first RC around
the end of August.
 - ~3 weeks from now till late August 2022 (Ongoing): Accept all
bugs, issues and minor improvements allowed in LTS [2]
 - 1 week: Accept only critical/blocker fixes, stabilize 4.17 
branch

 - end-August 2022 and onwards: Cut 4.17.1.0 RC1 and further RCs
if necessary, start/conclude vote, and finish release work

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

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

Regards,
Abhishek


Re: cloudstack - simulator Stopped working

2022-06-22 Thread Nux

Hello,

Can you please send some more information and logs?

---
Nux
www.nux.ro

On 2022-06-22 01:33, Antonio Perpinan wrote:
Hi I am teach cloudstack and the easiest way is using 
cloudstack/simulator


But recently it has completely stopped working.. any help, with this 
issue
which is a DB error during the setup or finding a similar software 
would be

highly appreciated.

--
Antonio Perpinan
Fundación
Código Libre Dominicano


Re: [VOTE] Apache Cloudstack 4.17.0.0 RC3

2022-05-27 Thread Nux

+1 (binding)

Thanks Nicolas.

Tested with KVM & XCP-Ng advanced zones.


---
Nux
www.nux.ro

On 2022-05-24 16:30, Nicolas Vazquez wrote:

All,

For testing purposes, I have uploaded convenience packages to:
https://download.cloudstack.org/testing/4.17.0.0-RC3/

The system VM template can be downloaded from here if needed:
https://download.cloudstack.org/systemvm/4.17

Regards,
Nicolas Vazquez


From: Nicolas Vazquez 
Date: Tuesday, 24 May 2022 at 11:59
To: users , dev@cloudstack.apache.org

Subject: [VOTE] Apache Cloudstack 4.17.0.0 RC3
Hi all,
I have created a 4.17.0.0 release (RC3) with the following artefacts
up for testing and a vote:

Git Branch and Commit SH:
https://github.com/apache/cloudstack/tree/4.17.0.0-RC20220524T1031
Commit: 8b9150cf3cb0bf469272ef1662993e092a36f747

Source release (checksums and signatures are available at the same 
location):

https://dist.apache.org/repos/dist/dev/cloudstack/4.17.0.0/

PGP release keys (signed using 
239A653975E13A0EEF5122A1656E1BCC8CB54F84):

https://dist.apache.org/repos/dist/release/cloudstack/KEYS

The vote will be open until 29th May 2022.

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,
Nicolas Vazquez


Re: Introduction

2022-05-12 Thread Nux

Welcome, Jamie!

---
Nux!
www.nux.ro

On 2022-05-12 15:23, Jamie Pell wrote:

Hi all,

I've recently started working with Ivet and helping her out with some
of the community marketing for the CloudStack community - so just
wanted to say hi to everybody.

Ivet has recently gone on maternity leave so I'm going to be
interacting on the mailing lists regularly now. I'm very much looking
forward to getting to know some of the great members of the community
and am open to any guidance anybody may have for me. I'm going to be
picking up organising of CCC this year amongst other tasks.

Kind regards,


Re: CloudStack Collaboration Conference 2022 - November 14-16

2022-04-05 Thread Nux

+1 to travel and face 2 face :)

---
Nux!
www.nux.ro

On 2022-04-05 15:45, Ivet Petrova wrote:

Hi all,

I am working on the idea for the CloudStack Collaboration Conference
2022. I was thinking that this time we can make it as a hybrid event
and the end of the year - November 14-16th.
We will choose one physical location in Europe and will also stream
the whole event online as previous year for the people who cannot/does
not want to travel.
If nobody is against, I will start some organization plan.

Kind regards,


  1   2   3   4   5   6   7   8   9   10   >