Re: [ANNOUNCE] New VP of Apache CloudStack - Rohit Yadav

[David Jumani]

Congrats Rohit, and thank you Simon!

From: Simon Weller 
Sent: Thursday, March 30, 2023 9:05 AM
To: dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org 
Cc: priv...@cloudstack.apache.org 
Subject: [ANNOUNCE] New VP of Apache CloudStack - Rohit Yadav

All,

I'm very pleased to announce that the ASF board has accepted the nomination
of Rohit Yadav to be the new VP of the Apache CloudStack project.

It has been my pleasure to serve as the VP over the past year, and I'd like
to thank the community for all of the support.

Rohit, congratulations and I wish you the best as you take on this new role.

-Simon

 

Re: Daan Hoogland - New ASF Member

[David Jumani]

Congrats Daan!

From: Paul Angus 
Sent: Friday, March 24, 2023 2:58 PM
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Subject: Daan Hoogland - New ASF Member



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: Hello Again!

[David Jumani]

Welcome back Kishan!

From: Kishan Kavala 
Sent: Thursday, March 9, 2023 4:11 PM
To: dev@cloudstack.apache.org 
Subject: Hello Again!

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

regards,
Kishan





 

Re: [ANNOUNCE] Ivet Petrova has joined the PMC

[David Jumani]

Congratulations Ivet!


From: Vishesh Jindal 
Sent: Wednesday, February 15, 2023 10:24 AM
To: us...@cloudstack.apache.org 
Cc: dev@cloudstack.apache.org ; 
priv...@cloudstack.apache.org 
Subject: Re: [ANNOUNCE] Ivet Petrova has joined the PMC

Congratulations Ivet!

From: Rohit Yadav 
Sent: Wednesday, February 15, 2023 7:14 AM
To: us...@cloudstack.apache.org 
Cc: dev@cloudstack.apache.org ; 
priv...@cloudstack.apache.org 
Subject: Re: [ANNOUNCE] Ivet Petrova has joined the PMC

Congratulations Ivet, well deserved!

Regards.

From: Martijn Struijk 
Sent: Wednesday, February 15, 2023 3:06:18 AM
To: us...@cloudstack.apache.org 
Cc: dev@cloudstack.apache.org ; 
priv...@cloudstack.apache.org 
Subject: Re: [ANNOUNCE] Ivet Petrova has joined the PMC

Congratulations Ivet!

On Tue, Feb 14, 2023 at 7:24 PM Nicolas Vazquez <
nicolas.vazq...@shapeblue.com> wrote:

> Congratulations Ivet!
>
> Regards,
> Nicolas Vazquez
> 
> From: Simon Weller 
> Sent: Tuesday, February 14, 2023 1:01 PM
> To: priv...@cloudstack.apache.org ;
> dev@cloudstack.apache.org ;
> us...@cloudstack.apache.org 
> Subject: [ANNOUNCE] Ivet Petrova has joined the PMC
>
> 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

[David Jumani]

Glad to have you on board Vishesh !

From: Wei ZHOU 
Sent: Thursday, February 2, 2023 1:23 PM
To: dev@cloudstack.apache.org 
Subject: Re: Hello

Welcome Vishesh !

-Wei

On Wed, 1 Feb 2023 at 16: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: Introduction

[David Jumani]

Glad to have you on board Kiran !

From: Rohit Yadav 
Sent: Thursday, February 2, 2023 2:59 PM
To: dev@cloudstack.apache.org 
Subject: Re: Introduction

Welcome to the community Kiran!


Regards.


From: Rahul Agarwal 
Sent: Thursday, February 2, 2023 12:13
To: dev@cloudstack.apache.org 
Subject: Re: Introduction

Welcome Kiran to Community.

From: Kiran Chavala 
Sent: 02 February 2023 10:53
To: dev@cloudstack.apache.org 
Subject: Introduction

Hi all,


This is Kiran, Just wanted to say hi to everyone in the community.

I've recently Shape blue as QA test engineer.

Previously I used to work with Citrix/Persistent for about 10 years in 
providing technical support to Cloudstack ( Citrix CloudPlatform and Rovius 
CloudPlatform) products

Looking forward to working with the community

Regards,
Kiran

kiran.chav...@shapeblue.com











 

Re: [DISCUSS] Github Discussions for CloudStack?

[David Jumani]

Sounds like a good idea
+1 for giving it a try!

From: Rohit Yadav 
Sent: Wednesday, December 14, 2022 2:37 PM
To: dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org 
Subject: [DISCUSS] Github Discussions for CloudStack?

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: [VOTE] Apache Cloudstack 4.17.0.0 RC3

[David Jumani]

-1

I've noticed a few issues wrt CKS :

  *   When creating a CKS cluster with multiple control plane nodes via the UI 
- the value of the control plane nodes is not passed - Fixed in 
https://github.com/apache/cloudstack/pull/6416
  *   When creating a CKS cluster in a network without internet access, it 
fails to come up as it tries to download the container images despite them 
already being there in the Kubernetes ISO - WIP fix in 
https://github.com/apache/cloudstack/pull/6418
  *   When upgrading a CKS cluster via the UI, it throws an error and the 
Kubernetes version can not be selected - Fixed in 
https://github.com/apache/cloudstack/pull/6417 [Thanks Pearl]


From: Nicolas Vazquez 
Sent: Tuesday, May 24, 2022 8:29 PM
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: GSoC mentee intro - Pritam Neog

[David Jumani]

Congrats Pritam and welcome!

From: Pritam Neog 
Sent: Saturday, May 21, 2022 7:14 PM
To: dev@cloudstack.apache.org 
Subject: GSoC mentee intro - Pritam Neog

Hi folks,

I'm Pritam Neog from Assam, India. I'm a sophomore pursuing a Computer
Science and Engineering degree. I'm so glad to be selected for GSoC 2022 as
a mentee for my project in OAuth2 integration in CloudStack.
I'd like to thank my mentors Nicolas Vazquez and Boris Stoyanov for helping
me shape my proposal and also Wei Zhou who've helped me a lot during my
very first CloudStack builds.

I hope to learn a lot and contribute as much as possible to this community
❤️.

Regards,
Pritam

 

Re: GSoC 2022 Mentee Introduction

[David Jumani]

Congrats Yashika and welcome!

From: Yashika Sarkar 
Sent: Saturday, May 21, 2022 11:51 PM
To: dev@cloudstack.apache.org 
Subject: GSoC 2022 Mentee Introduction

Hello everyone,

I'm Yashika Sarkar, an undergraduate student in electrical engineering and
I'm here to announce that I have been accepted into GSoC 22 under The ACS.

I want to take a moment to thank all my  mentors, GSoC org admins,
David jumani who moulded me back into an healthy state of mind
and Boris Stoyanov for his affirmation and acknowledgment throughout.

I am eagerly looking forward to the journey ahead and I'll put my best
efforts into being a sincere and invested contributor.

Thank you and I wish you all a good day ahead.

Regards,
Yashika

 

Re: GSoC 2022 Mentee Introduction - Daman Arora

[David Jumani]

Congrats Daman and welcome!

From: Daman Arora 
Sent: Saturday, May 21, 2022 1:38 AM
To: dev@cloudstack.apache.org 
Subject: GSoC 2022 Mentee Introduction - Daman Arora

Hello everyone,

I am Daman Arora from Ottawa, Canada. I'm excited to announce that I will
work as a GSoC Mentee for CloudStack over the next few months under
the guidance of my amazing mentors.
Having contributed to CloudStack since last year, I am thrilled about this
opportunity to take my contributions to a new level.

Furthermore, I would like to give a special shout-out to my mentors, Pearl
Dsilva, Harikrishna, and GSoC Org Admin, Boris Stoyanov, for their constant
support throughout the process.

Cheers, and have a wonderful weekend.

Best,
Daman Arora.

 

Re: Introduction

[David Jumani]

Welcome Jamie!

From: Jamie Pell 
Sent: Thursday, May 12, 2022 7:53 PM
To: dev@cloudstack.apache.org 
Subject: Introduction

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: Hi (Again)

[David Jumani]

That doesn't seem like a big change from what you've already been doing :D

There's a PR for it https://github.com/apache/cloudstack/pull/4828

From: Paul Angus 
Sent: Monday, September 13, 2021 4:50 PM
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Subject: Hi (Again)

Hey All,

So, I’ve moved over to the Dark Side, and I’m now purely a user of CloudStack 
with Ticketmaster/Live Nation.  I’m mostly going to be all about breaking 
things rather than fixing them 

…Starting off with:  As root admin I can list all VMs including ones in 
projects via cmk -list virtualmachines projectid=-1
Is there a way to do the same in the UI?

Cheers!

Paul.

This message is confidential and may be legally privileged or otherwise 
protected from disclosure. If you are not the intended recipient, please 
telephone or email the sender and delete this message and any attachment from 
your system; you must not copy or disclose the contents of this message or any 
attachment to any other person. We may monitor email traffic and the content of 
internal and external messages sent to and from us to ensure compliance with 
internal policies and for the purposes of security.

Ticketmaster UK Limited. Registered Office: 30 St John Street, London EC1M 4AY. 
Registered in England and Wales. Company Number 02662632.

 

Re: [DISCUSS] Upgrade to Vue3 library

[David Jumani]

Thanks for the answers Hoang, you've got my support

From: Nguyen Mai Hoang 
Sent: Friday, September 10, 2021 7:30 AM
To: dev@cloudstack.apache.org 
Subject: Re: [DISCUSS] Upgrade to Vue3 library

Hi all,
cc @Daan, @Sven, @Rohit, and @David.
Thank you for your responses to my ideas.
1. As far as I know, Vue3 is still being developed and after a few experiments 
in Cloudstack, I found that it works quite stably
2. The release frequency of the new version is usually monthly. I'm using 
version 3.1and the latest one is 3.2.
3. From what I experimented with in my draft PR, the conversion accounts for 
about 60% to 70% and the support from the community is pretty helpful. In case 
I get any problems, I will definitely get in touch.
4. I think the duration of 1 month would be enough.
5. Also completing it according to 4.17 milestones is totally feasible.

Thanks & Regards.

On 2021/09/09 20:28:28, Sven Vogel  wrote:
> Hi Hoang,
>
> Interesting PR and it Sound like a good plan.
>
> Cheers
>
> Sven
>
> __
>
> Sven Vogel
> Senior Manager Research and Development - Cloud and Infrastructure
>
> EWERK DIGITAL GmbH
> Br?hl 24, D-04109 Leipzig
> P +49 341 42649 - 99
> F +49 341 42649 - 98
> s.vo...@ewerk.com
> www.ewerk.com<http://www.ewerk.com>
>
> Gesch?ftsf?hrer:
> Dr. Erik Wende, Hendrik Schubert, Tassilo M?schke
> Registergericht: Leipzig HRB 9065
>
> Support:
> +49 341 42649 555
>
> Zertifiziert nach:
> ISO/IEC 27001:2013
> DIN EN ISO 9001:2015
> DIN ISO/IEC 2-1:2018
>
> ISAE 3402 Typ II Assessed
>
> EWERK-Blog<https://blog.ewerk.com/> | 
> LinkedIn<https://www.linkedin.com/company/ewerk-group> | 
> Xing<https://www.xing.com/company/ewerk> | 
> Twitter<https://twitter.com/EWERK_Group> | 
> Facebook<https://de-de.facebook.com/EWERK.Group/>
>
>
> Ausk?nfte und Angebote per Mail sind freibleibend und unverbindlich.
>
> Disclaimer Privacy:
> Der Inhalt dieser E-Mail (einschlie?lich etwaiger beigef?gter Dateien) ist 
> vertraulich und nur f?r den Empf?nger bestimmt. Sollten Sie nicht der 
> bestimmungsgem??e Empf?nger sein, ist Ihnen jegliche Offenlegung, 
> Vervielf?ltigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte 
> informieren Sie in diesem Fall unverz?glich den Absender und l?schen Sie die 
> E-Mail (einschlie?lich etwaiger beigef?gter Dateien) von Ihrem System. Vielen 
> Dank.
>
> The contents of this e-mail (including any attachments) are confidential and 
> may be legally privileged. If you are not the intended recipient of this 
> e-mail, any disclosure, copying, distribution or use of its contents is 
> strictly prohibited, and you should please notify the sender immediately and 
> then delete it (including any attachments) from your system. Thank you.
>
> 
> Von: Rohit Yadav 
> Gesendet: Thursday, September 9, 2021 2:40:29 PM
> An: dev@cloudstack.apache.org 
> Betreff: Re: [DISCUSS] Upgrade to Vue3 library
>
> +1
>
> I think it's good idea if Vue and Antd are going to cease support for current 
> dependencies sometime in future. Based on VueJS's roadmap board looks like 
> they're going to support the last 2.7 release + then support if for next 18 
> months.
>
> Based on your current work-in-progress PR, it looks like you've the 
> initiative under control - let us know what kind of timeline/effort you would 
> require and assistance from community in terms of QA/testing?
>
> +1 to what David suggests, the sooner we get it into main towards 4.17 
> milestone, we've at least 3-5months to stabilises the UI (for any 
> regressions/issues).
>
>
> Regards.
>
> 
> From: David Jumani 
> Sent: Thursday, September 9, 2021 16:46
> To: dev@cloudstack.apache.org 
> Subject: Re: [DISCUSS] Upgrade to Vue3 library
>
> Hi Hoang,
>
> I like the idea of migrating to Vue 3 which will eventually be needed, and in 
> my opinion, the sooner the better :)
>
> I had a look at the migration guide as well as the breaking changes and so I 
> have a few things on which I'd like clarity :
> 1. I see that Vue3 is still being developed, so how is the stability ?
> 2. How is the vue release cycle and which 3.x version are we targetting ?
> 3. There are significant changes in some components and I see that you've 
> already created a draft PR, So will you be taking charge of the migration and 
> would you require any assistance from the community ?
> 4. What would be the timeline required to complete it ?
> 5. If it can be done relatively quickly, say within a month, would it make 
> sense to target it for 4.17 or if it would take longer to target a further 
> release ? (I'd like the

Re: [DISCUSS] Upgrade to Vue3 library

[David Jumani]

Hi Hoang,

I like the idea of migrating to Vue 3 which will eventually be needed, and in 
my opinion, the sooner the better :)

I had a look at the migration guide as well as the breaking changes and so I 
have a few things on which I'd like clarity :
1. I see that Vue3 is still being developed, so how is the stability ?
2. How is the vue release cycle and which 3.x version are we targetting ?
3. There are significant changes in some components and I see that you've 
already created a draft PR, So will you be taking charge of the migration and 
would you require any assistance from the community ?
4. What would be the timeline required to complete it ?
5. If it can be done relatively quickly, say within a month, would it make 
sense to target it for 4.17 or if it would take longer to target a further 
release ? (I'd like there to be sufficient time to thoroughly test prior to a 
release)

Thanks,
David

From: Nguyen Mai Hoang 
Sent: Tuesday, September 7, 2021 6:19 AM
To: dev@cloudstack.apache.org 
Subject: [DISCUSS] Upgrade to Vue3 library

Hi All,

We are upgrading a Vue 2 application to Vue 3 on CloudStack. As far as our 
investigation goes, Vue 3 does support migration from Vue 2 to Vue 3 by using 
`@vue/compat` (aka "the migration build"). However, it is worth mentioning that 
there are some incompatible features (please refer to: 
https://v3.vuejs.org/guide/migration/migration-build.html#overview).
The biggest differences between Vue 2 and Vue 3 on Cloudstack are:
- mount: https://v3.vuejs.org/guide/migration/mount-changes.html#overview
- Slots: https://v3.vuejs.org/guide/component-slots.html#slots
- Async components: 
https://v3.vuejs.org/guide/migration/async-components.html#async-components
- Events: https://v3.vuejs.org/guide/migration/events-api.html#overview
- Watch: https://v3.vuejs.org/guide/migration/watch.html#overview

In order to make them compatible with Vue 3, it is necessary to upgrade or 
replace some libraries as well as some other components, which are listed below:
- Antd: https://2x.antdv.com/components/overview
- Router: https://next.router.vuejs.org/installation.html
- I18n: https://vue-i18n.intlify.dev/introduction.html
- Clipboard: https://www.npmjs.com/package/vue3-clipboard
- Vue-ls (https://www.npmjs.com/package/vue-ls) => vue-web-storage 
(https://github.com/ankurk91/vue-web-storage)

These upgrades and replacements will require changes in source code, structure 
and elements in UI. We would like to have your opinions about it.

Thank you and best regards,

 

Re: Console proxy creation failure

[David Jumani]

If that's the case, you can remove the host, reset the IP table rules, 
reinstall the cloudstack agent and add the required IP tables rules as 
mentioned here (as some iptable rules are added to allow the console proxy 
communicate with the vnc port on the host)
https://docs.cloudstack.apache.org/en/latest/installguide/hypervisor/kvm.html
https://docs.cloudstack.apache.org/en/latest/installguide/hypervisor/kvm.html#open-ports-in-rhel-centos

From: technologyrss.mail 
Sent: Thursday, September 2, 2021 11:13 AM
To: David Jumani ; us...@cloudstack.apache.org 
; dev@cloudstack.apache.org 

Subject: Re: Console proxy creation failure


I see iptables issue from my kvm host. after some time iptables service stop 
then I can't access any vm.


---

Alamin



On 9/2/2021 10:12 AM, David Jumani wrote:
Could you send the /var/log/cloud.log in the console proxy VM ? Also try 
destroying and recreating the proxy VM






From: technologyrss.mail 
<mailto:technologyrss.m...@gmail.com>
Sent: Wednesday, September 1, 2021 6:58 AM
To: us...@cloudstack.apache.org<mailto:us...@cloudstack.apache.org> 
<mailto:us...@cloudstack.apache.org>; David Jumani 
<mailto:david.jum...@shapeblue.com>; 
dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org> 
<mailto:dev@cloudstack.apache.org>
Subject: Fwd: Console proxy creation failure



Thank you so much ! Yes, RAM issue. I increase RAM then fix but I see different 
error like I can't access vm console from browser. Please see below image.


ACS log file from below link.

https://drive.google.com/file/d/15C20k1wYlDFNReyY1iYoyfRdJodwdxiU/view?usp=sharing


[cid:part2.2E081B89.7FF30886@gmail.com]


---
Alamin.


On 8/31/2021 2:38 PM, David Jumani wrote:
Hi

At just a glance, It looks like there isn't sufficient memory for the Console 
proxy to come up (by default it needs 1024 MB)
Try adding more memory or increasing the memory overprovisioning factor in the 
configuration / global settings tab






From: technologyrss.mail 
<mailto:technologyrss.m...@gmail.com>
Sent: Tuesday, August 31, 2021 12:31 PM
To: us...@cloudstack.apache.org<mailto:us...@cloudstack.apache.org> 
<mailto:us...@cloudstack.apache.org>; 
dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org> 
<mailto:dev@cloudstack.apache.org>
Subject: Console proxy creation failure


Hi,

I am able to setup ACS using centos 7.9. all service are properly working fine. 
But when I create basic zone then I see error like below .

ACS server : Centos 0s 7.9
NFS server : Centos 0s 7.8
KVM server : Centos 0s 7.8

[cid:part1.B6819867.0C83CE47@gmail.com]

Secondary Storage VM working fine but can't start proxy vm. what is issue?

[cid:part2.99CE7C85.B5717BC5@gmail.com]

This is system capacity like as below.


[cid:part3.389FB6FD.77D44A7C@gmail.com]


Please give me any idea..


Thanks, Alamin

 

Re: Console proxy creation failure

[David Jumani]

Could you send the /var/log/cloud.log in the console proxy VM ? Also try 
destroying and recreating the proxy VM

From: technologyrss.mail 
Sent: Wednesday, September 1, 2021 6:58 AM
To: us...@cloudstack.apache.org ; David Jumani 
; dev@cloudstack.apache.org 

Subject: Fwd: Console proxy creation failure



Thank you so much ! Yes, RAM issue. I increase RAM then fix but I see different 
error like I can't access vm console from browser. Please see below image.


ACS log file from below link.

https://drive.google.com/file/d/15C20k1wYlDFNReyY1iYoyfRdJodwdxiU/view?usp=sharing


[cid:part2.B70A23A0.CADBC208@gmail.com]


---
Alamin.


On 8/31/2021 2:38 PM, David Jumani wrote:
Hi

At just a glance, It looks like there isn't sufficient memory for the Console 
proxy to come up (by default it needs 1024 MB)
Try adding more memory or increasing the memory overprovisioning factor in the 
configuration / global settings tab






From: technologyrss.mail 
<mailto:technologyrss.m...@gmail.com>
Sent: Tuesday, August 31, 2021 12:31 PM
To: us...@cloudstack.apache.org<mailto:us...@cloudstack.apache.org> 
<mailto:us...@cloudstack.apache.org>; 
dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org> 
<mailto:dev@cloudstack.apache.org>
Subject: Console proxy creation failure


Hi,

I am able to setup ACS using centos 7.9. all service are properly working fine. 
But when I create basic zone then I see error like below .

ACS server : Centos 0s 7.9
NFS server : Centos 0s 7.8
KVM server : Centos 0s 7.8

[cid:part1.B6819867.0C83CE47@gmail.com]

Secondary Storage VM working fine but can't start proxy vm. what is issue?

[cid:part2.99CE7C85.B5717BC5@gmail.com]

This is system capacity like as below.


[cid:part3.389FB6FD.77D44A7C@gmail.com]


Please give me any idea..


Thanks, Alamin

 

Re: [Discussion] Release Cycle

[David Jumani]

Hi Gabriel,


  1.  I'm a +1 on having regular releases between LTS ones and the reasoning 
behind it. While stability is great, it will also be nice to have a "pilot" as 
you mentioned which the community can test and issues are resolved in the 
following LTS, rather than waiting for 2 - 3 releases to get something 
allegedly stable in, which could still have issues reported by users.
  2.  I'm for having 1 Regular release (Mar-Apr) followed by an LTS one (~6 
months down the line) each year. Wrt the LTS releases, they should be supported 
for 1.5 to 2 years (at least 6 months after the following LTS is out). If that 
might be too much then a single alternating release annually around the same 
dates
  3.  No strong opinion on this but it does seem like a good idea, but not sure 
how religiously people will update the new page with every feature they intend 
to add and follow up on it


From: Gabriel Bräscher 
Sent: Tuesday, August 31, 2021 11:14 PM
To: dev 
Subject: [Discussion] Release Cycle

Hello,

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

1. LTS and Regular releases

2. Releases period

3. Enhance roadmap and Release cycle for users

 1 LTS and Regular releases

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

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

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

For reference, here follow the past releases:

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

 2 Releases period


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

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

 3 Enhance roadmap and Release cycle for users

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

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

Please let me know what you think.

Best regards,
Gabriel.

 

Re: Console proxy creation failure

[David Jumani]

Hi

At just a glance, It looks like there isn't sufficient memory for the Console 
proxy to come up (by default it needs 1024 MB)
Try adding more memory or increasing the memory overprovisioning factor in the 
configuration / global settings tab

From: technologyrss.mail 
Sent: Tuesday, August 31, 2021 12:31 PM
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Subject: Console proxy creation failure


Hi,

I am able to setup ACS using centos 7.9. all service are properly working fine. 
But when I create basic zone then I see error like below .

ACS server : Centos 0s 7.9
NFS server : Centos 0s 7.8
KVM server : Centos 0s 7.8

[cid:part1.B6819867.0C83CE47@gmail.com]

Secondary Storage VM working fine but can't start proxy vm. what is issue?

[cid:part2.99CE7C85.B5717BC5@gmail.com]

This is system capacity like as below.


[cid:part3.389FB6FD.77D44A7C@gmail.com]


Please give me any idea..


Thanks, Alamin

 

[ANNOUNCE] CloudStack Kubernetes Provider v1.0.0 Release

[David Jumani]

# CloudStack Kubernetes Provider v1.0.0 Release

The Apache CloudStack project is pleased to announce the first release of 
CloudStack Kubernetes Provider v1.0.0 that facilitates Kubernetes deployments 
on Cloudstack.

It allows Kubernetes to dynamically allocate IP addresses and the respective 
networking rules on CloudStack to ensure seamless TCP, UDP and TCP-Proxy 
LoadBalancer deployments on Kubernetes. This was historically part of the 
Kubernetes codebase which was later removed and donated to the project to allow 
for further maintenance of the provider plugin.

# Documentation

https://docs.cloudstack.apache.org/en/latest/plugins/cloudstack-kubernetes-provider.html

# Downloads

The official source code for the v1.0.0 release can be downloaded from the 
archive page:
https://archive.apache.org/dist/cloudstack/releases/kubernetes-provider-v1.0.0/

In addition to the official source code release, individual contributors have 
also made convenient images which can be found on DockerHub:
https://hub.docker.com/layers/apache/cloudstack-kubernetes-provider/v1.0.0/images/sha256-8c2408eccd30eef24cfa72cfbdd912aa4261bc032406d2d078a85dd7246b368d?context=explore


 

Re: [DRAFT] [ANNOUNCE] Apache CloudStack Kubernetes Provider v1.0.0

[David Jumani]

Thanks all for reviewing it
Since there are no objections, I'll publish them today.

From: Suresh Anaparti 
Sent: Wednesday, August 25, 2021 2:20 PM
To: dev@cloudstack.apache.org ; 
market...@cloudstack.apache.org 
Subject: Re: [DRAFT] [ANNOUNCE] Apache CloudStack Kubernetes Provider v1.0.0

+1, checked the text and web links.

Regards,
Suresh

On 23/08/21, 5:08 PM, "David Jumani"  wrote:

Hi All,

Kindly review the CloudStack Kubernetes Provider v1.0.0 announcement draft 
including links, etc.

### DRAFT START 

# CloudStack Kubernetes Provider v1.0.0 Release

The Apache CloudStack project is pleased to announce the first release of 
CloudStack Kubernetes Provider v1.0.0 that facilitates Kubernetes deployments 
on Cloudstack.

It allows Kubernetes to dynamically allocate IP addresses and the 
respective networking rules on CloudStack to ensure seamless TCP, UDP and 
TCP-Proxy LoadBalancer deployments on Kubernetes. This was historically part of 
the Kubernetes codebase which was later removed and donated to the project to 
allow for further maintenance of the provider plugin.

# Documentation


https://docs.cloudstack.apache.org/en/latest/plugins/cloudstack-kubernetes-provider.html

# Downloads

The official source code for the v1.0.0 release can be downloaded from the 
archive page:

https://archive.apache.org/dist/cloudstack/releases/kubernetes-provider-v1.0.0/

In addition to the official source code release, individual contributors 
have also made convenient images which can be found on DockerHub:

https://hub.docker.com/layers/apache/cloudstack-kubernetes-provider/v1.0.0/images/sha256-8c2408eccd30eef24cfa72cfbdd912aa4261bc032406d2d078a85dd7246b368d?context=explore

### DRAFT END ###

Thanks,
David








 

[DRAFT] [ANNOUNCE] Apache CloudStack Kubernetes Provider v1.0.0

[David Jumani]

Hi All,

Kindly review the CloudStack Kubernetes Provider v1.0.0 announcement draft 
including links, etc.

### DRAFT START 

# CloudStack Kubernetes Provider v1.0.0 Release

The Apache CloudStack project is pleased to announce the first release of 
CloudStack Kubernetes Provider v1.0.0 that facilitates Kubernetes deployments 
on Cloudstack.

It allows Kubernetes to dynamically allocate IP addresses and the respective 
networking rules on CloudStack to ensure seamless TCP, UDP and TCP-Proxy 
LoadBalancer deployments on Kubernetes. This was historically part of the 
Kubernetes codebase which was later removed and donated to the project to allow 
for further maintenance of the provider plugin.

# Documentation

https://docs.cloudstack.apache.org/en/latest/plugins/cloudstack-kubernetes-provider.html

# Downloads

The official source code for the v1.0.0 release can be downloaded from the 
archive page:
https://archive.apache.org/dist/cloudstack/releases/kubernetes-provider-v1.0.0/

In addition to the official source code release, individual contributors have 
also made convenient images which can be found on DockerHub:
https://hub.docker.com/layers/apache/cloudstack-kubernetes-provider/v1.0.0/images/sha256-8c2408eccd30eef24cfa72cfbdd912aa4261bc032406d2d078a85dd7246b368d?context=explore

### DRAFT END ###

Thanks,
David

 

[RESULT] [VOTE] Apache CloudStack Kubernetes Provider v1.0.0 (RC1)

[David Jumani]

Hi All,

The vote for CloudStack Kubernetes Provider v1.0.0 *passes* with
5 PMC + 2 non-PMC votes.

+1 (PMC / binding)
5 people (Rohit, Daan, Gabriel, Nicolas, Boris)

+1 (non-binding)
2 people (Abhishek, Suresh)

0
none

-1
none

Thanks to everyone participating. I will now prepare the release announcement 
to go out next week and publish the images to Dockerhub.


On 12/08/21, 1:52 PM, "Boris Stoyanov"  wrote:

+1 (binding), have not tested it personally but basing my +1 on testing 
done by Abhishek

From: David Jumani 
Date: Wednesday, 4 August 2021, 14:42
To: dev@cloudstack.apache.org , users 

Subject: [VOTE] Apache CloudStack Kubernetes Provider v1.0.0 (RC1)
Hi All,

I've created the initial CloudStack Kubernetes Provider release v1.0.0, 
with the following artifacts up for a vote:

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

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

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

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

The docker image can be found at 
https://hub.docker.com/r/apache/cloudstack-kubernetes-provider

The documentation for the same can be found at

https://github.com/apache/cloudstack-documentation/blob/main/source/plugins/cloudstack-kubernetes-provider.rst

https://github.com/apache/cloudstack-kubernetes-provider/blob/main/README.md#deployment
(be sure to replace the image version 
`apache/cloudstack-kubernetes-provider:v1.0.0` with 
`apache/cloudstack-kubernetes-provider:v1.0.0-RC20210804T0500`)

The vote will be open until 08 August 2021.

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

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

Thanks,
David







 

Re: 2FA

[David Jumani]

Hi Rakesh,

MFA is generally done via an IAM rather than on a per-application basis. As 
Simon had mentioned, CloudStack does support SAML / LDAP so, in a general / 
corporate use case, the MFA would go there. So I do not think adding support 
for 2FA will add any significant benefit
That being said, I'll be happy to review any PR that's raised

From: Simon Weller 
Sent: Wednesday, August 11, 2021 12:31 AM
To: users ; dev 
Subject: Re: 2FA

Rakesh,

ACS does support SAML2 and in order to deploy 2FA/MFA, you could integrate it 
with an Identity and Access Management System such as Keycloak 
(https://www.keycloak.org/).

-Si


From: Rakesh Venkatesh 
http://www.rakeshv@gmail.com>>
Sent: Tuesday, August 10, 2021 4:34 AM
To: users ; dev 
Subject: 2FA

Hello

Has anyone thought about 2FA or about how to implement it in cloudstack?
Looks like this will be good addition to enhance the security. I have some
idea about implementing in the backend but dont have much idea on how to
display the QR code in ui or other functionalities which is needed for
frontend part.

--
Thanks and regards
Rakesh

 

Re: [VOTE] Apache CloudStack Kubernetes Provider v1.0.0 (RC1)

[David Jumani]

Hi All,

The vote is still open as we need 3 binding +1s
Requesting PMCs to please cast their vote

From: David Jumani 
Sent: Tuesday, August 10, 2021 1:55 PM
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Subject: Re: [VOTE] Apache CloudStack Kubernetes Provider v1.0.0 (RC1)

Hi All,

The vote for CloudStack Kubernetes Provider v1.0.0 *passes* with
1 PMC + 2 non-PMC votes.

+1 (PMC / binding)
1 person (Rohit)

+1 (non-binding)
2 people (Abhishek, Suresh)

0
none

-1
none

Thanks to everyone participating. I will now prepare the release announcement 
to go out later this week and publish the images to Dockerhub.


From: Suresh Anaparti 
Sent: Tuesday, August 10, 2021 11:40 AM
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Subject: Re: [VOTE] Apache CloudStack Kubernetes Provider v1.0.0 (RC1)

+1

Tested basic deployment for the Traefik ingress controller, using the 
Kubernetes Provider with the below RC build (Env: ACS main + KVM + K8s Cluster 
v1.16.3).

Regards,
Suresh

On 04/08/21, 5:12 PM, "David Jumani"  wrote:

Hi All,

I've created the initial CloudStack Kubernetes Provider release v1.0.0, 
with the following artifacts up for a vote:

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

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

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

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

The docker image can be found at 
https://hub.docker.com/r/apache/cloudstack-kubernetes-provider

The documentation for the same can be found at

https://github.com/apache/cloudstack-documentation/blob/main/source/plugins/cloudstack-kubernetes-provider.rst

https://github.com/apache/cloudstack-kubernetes-provider/blob/main/README.md#deployment
(be sure to replace the image version 
`apache/cloudstack-kubernetes-provider:v1.0.0` with 
`apache/cloudstack-kubernetes-provider:v1.0.0-RC20210804T0500`)

The vote will be open until 08 August 2021.

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

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

Thanks,
David











 

Re: [VOTE] Apache CloudStack Kubernetes Provider v1.0.0 (RC1)

[David Jumani]

Hi All,

Please ignore the previous mail, the voting thread is still open

From: David Jumani 
Sent: Tuesday, August 10, 2021 1:55 PM
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Subject: Re: [VOTE] Apache CloudStack Kubernetes Provider v1.0.0 (RC1)

Hi All,

The vote for CloudStack Kubernetes Provider v1.0.0 *passes* with
1 PMC + 2 non-PMC votes.

+1 (PMC / binding)
1 person (Rohit)

+1 (non-binding)
2 people (Abhishek, Suresh)

0
none

-1
none

Thanks to everyone participating. I will now prepare the release announcement 
to go out later this week and publish the images to Dockerhub.


From: Suresh Anaparti 
Sent: Tuesday, August 10, 2021 11:40 AM
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Subject: Re: [VOTE] Apache CloudStack Kubernetes Provider v1.0.0 (RC1)

+1

Tested basic deployment for the Traefik ingress controller, using the 
Kubernetes Provider with the below RC build (Env: ACS main + KVM + K8s Cluster 
v1.16.3).

Regards,
Suresh

On 04/08/21, 5:12 PM, "David Jumani"  wrote:

Hi All,

I've created the initial CloudStack Kubernetes Provider release v1.0.0, 
with the following artifacts up for a vote:

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

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

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

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

The docker image can be found at 
https://hub.docker.com/r/apache/cloudstack-kubernetes-provider

The documentation for the same can be found at

https://github.com/apache/cloudstack-documentation/blob/main/source/plugins/cloudstack-kubernetes-provider.rst

https://github.com/apache/cloudstack-kubernetes-provider/blob/main/README.md#deployment
(be sure to replace the image version 
`apache/cloudstack-kubernetes-provider:v1.0.0` with 
`apache/cloudstack-kubernetes-provider:v1.0.0-RC20210804T0500`)

The vote will be open until 08 August 2021.

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

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

Thanks,
David











 

Re: [VOTE] Apache CloudStack Kubernetes Provider v1.0.0 (RC1)

[David Jumani]

Hi All,

The vote for CloudStack Kubernetes Provider v1.0.0 *passes* with
1 PMC + 2 non-PMC votes.

+1 (PMC / binding)
1 person (Rohit)

+1 (non-binding)
2 people (Abhishek, Suresh)

0
none

-1
none

Thanks to everyone participating. I will now prepare the release announcement 
to go out later this week and publish the images to Dockerhub.


From: Suresh Anaparti 
Sent: Tuesday, August 10, 2021 11:40 AM
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Subject: Re: [VOTE] Apache CloudStack Kubernetes Provider v1.0.0 (RC1)

+1

Tested basic deployment for the Traefik ingress controller, using the 
Kubernetes Provider with the below RC build (Env: ACS main + KVM + K8s Cluster 
v1.16.3).

Regards,
Suresh

On 04/08/21, 5:12 PM, "David Jumani"  wrote:

Hi All,

I've created the initial CloudStack Kubernetes Provider release v1.0.0, 
with the following artifacts up for a vote:

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

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

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

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

The docker image can be found at 
https://hub.docker.com/r/apache/cloudstack-kubernetes-provider

The documentation for the same can be found at

https://github.com/apache/cloudstack-documentation/blob/main/source/plugins/cloudstack-kubernetes-provider.rst

https://github.com/apache/cloudstack-kubernetes-provider/blob/main/README.md#deployment
(be sure to replace the image version 
`apache/cloudstack-kubernetes-provider:v1.0.0` with 
`apache/cloudstack-kubernetes-provider:v1.0.0-RC20210804T0500`)

The vote will be open until 08 August 2021.

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

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

Thanks,
David








 

[VOTE] Apache CloudStack Kubernetes Provider v1.0.0 (RC1)

[David Jumani]

Hi All,

I've created the initial CloudStack Kubernetes Provider release v1.0.0, with 
the following artifacts up for a vote:

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

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

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

The docker image can be found at 
https://hub.docker.com/r/apache/cloudstack-kubernetes-provider

The documentation for the same can be found at
https://github.com/apache/cloudstack-documentation/blob/main/source/plugins/cloudstack-kubernetes-provider.rst
https://github.com/apache/cloudstack-kubernetes-provider/blob/main/README.md#deployment
(be sure to replace the image version 
`apache/cloudstack-kubernetes-provider:v1.0.0` with 
`apache/cloudstack-kubernetes-provider:v1.0.0-RC20210804T0500`)

The vote will be open until 08 August 2021.

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

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

Thanks,
David

 

Re: [ANNOUNCE] Nicolas Vazquez has joined the PMC

[David Jumani]

Congrats Nicolas!!!

From: Gabriel Beims Bräscher 
Sent: Tuesday, August 3, 2021 12:58 AM
To: dev 
Subject: [ANNOUNCE] Nicolas Vazquez has joined the PMC

Hello @dev,

I am pleased to announce that Nicolas Vazquez was invited to join the
Project Management Committee (PMC) for Apache CloudStack, and he has
gracefully accepted.

Nicolas has been working actively on the project since 2015 and has proven
a great contributor, committer and now will be part of the PMC.

Please join me in congratulating Nicolas and wish him wisdom in his new
role.

On behalve of the PMC,
--
Gabriel Beims Bräscher
Apache CloudStack PMC Chair

 

Re: Code executed twice while deploying VM

[David Jumani]

The way the deployVM command works is that it first runs the create() where it 
checks the requirements, returns the jobid and then the execute() where it 
starts the VM if specified.
Perhaps the VM can be started in create() itself if startvm is true and return 
a future which is then checked in execute()


From: Rakesh Venkatesh 
Sent: Thursday, July 29, 2021 12:47 PM
To: dev 
Subject: Re: Code executed twice while deploying VM

Is there a way second computation can be avoided if "startvm" or some other
flag to indicate starting the vm flag is passed?

On Thu, Jul 29, 2021 at 8:15 AM David Jumani 
wrote:

> Hi Rakesh,
>
> If I'm right, that's because a VM can be deployed without starting it. It
> initially checks whether the VM can be deployed, and once again before
> starting as things might change (if started some time after deployment)
> I'm all for optimizing the code but this is the reason I see the
> duplication of code / computation
>
> 
> From: Rakesh Venkatesh 
> http://www.rakeshv@gmail.com>>
> Sent: Wednesday, July 28, 2021 2:34 PM
> To: users ; dev 
> Subject: Code executed twice while deploying VM
>
> Hello Users/Devs
>
>
> Today I observed that while deploying a VM, the same code is executed
> twice: the first time, while trying to find a suitable deployment
> destination and the second time, while trying to start a VM. I think this
> is a redundant process and also time-consuming since the same calculations
> are done twice. These are the one of the duplicate logs
>
> Asyn job is created
> 2021-07-28 09:01:27,964 (logid:10ac9f28) ZoneWideStoragePoolAllocator to
> find storage pool
>
> Now it finds a suitable destination
> Returning Deployment Destination:
>
> Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))]
> : Dest[Zone(1)-Pod(1)-Cluster(1)-Host(1)-Storage(Volume(23|ROOT-->Pool(3))]
>
> VM start attempt #1
>
> 2021-07-28 09:01:36,039 job-174/job-175 ctx-b815930d) (logid:10ac9f28)
> ZoneWideStoragePoolAllocator to find storage pool
>
>
> From the above two logs, I can see that starting at 9:01:27 and 09:01:36,
> its doing the same calculations.
> if I see the logs before and after the above-mentioned logs, they are all
> same. They try to find a suitable host, a suitable storage pool, and so on.
> In the production platform, the calculation is done twice and this takes a
> lot of time to deploy a VM.
>
> Do you guys also think this is an issue or redundant process and needs to
> be improved? Or any other suggestions to avoid double calculation?
>
> --
> Thanks and regards
> Rakesh
>
>
>
>

--
Thanks and regards
Rakesh venkatesh

 

Re: [PROPOSE] RM for CloudStack Kubernetes Provider v1.0

[David Jumani]

Thanks for your support.
As an RM, I'll need access to the cloudstack / cloudstack-kubernetes-provider 
dockerhub repo.
I'll also need my GPG key added to the KEYS file in the apache repo. Could a 
PMC help me out with that ?



pub   rsa4096 2021-07-29 [SC] [expires: 2023-07-29]
  C7E3B47728631AA39FB026FC92D88ECF4D63C923
uid   [ultimate] David Jumani 
sig 392D88ECF4D63C923 2021-07-29  David Jumani 


-BEGIN PGP PUBLIC KEY BLOCK-

mQINBGECVCwBEADN8ATXJEXavjqATmi3pC8T58Lyoq6oamIzR7qL/qfxha+eHM5M
zxR1plKqabcgC2I5R0wBbElVpO5Df27IJYOeH9COX/c8MxF8Urrk+Pj+esd8MncX
pIBIUifmBgTsglMOT3ohuP7igSpqFyVhs+WM0iLIlqq5YRTQ24VJRLfX29SUswVx
G6b//Ey+5lqecHjkAufw/9sSgzRJChnwIYkJno/v+4asR5RqzFIfZaGY8o3updff
Q7iPD6SZM3Dthjfw3xE2Snt+FZ+TX5nSgdDrND/kjMDtYxg6hM6CZLY48dBNmyUK
mZWQ+q+nZfJt/cgiRgcNySjKMK8yjtxw+wsKGWFJpzMasHASKSZVgIDPLWIVrk7G
xOisNF2FHyqZSFL3UanCrP4Tc8BOhN9iPQmk/LHEqYEBsSk6hHsDBXLJAd1RLvfV
+ehYWZwAXvLx76GX1ws3hLzzCCpq7g8RbJ4JZREWDUvgGl7k0r7BCeCreVIf1xdR
fcInDgCZeVfBq94y4U3hw/8juciCEbKOAbibVR1oWIBcwHqdifzPo7OsFci8Fmz9
UpQjRcvMm4INEtfyjZY9aXWrGCWXAC77QeCGln2TIqGycHiAdOliccrc6jv2MpJr
rBBK5MVgQmTMN563w2EwLwZPwKUqCLrK4lurkZlL+A9YPOOhN5OU06yl+wARAQAB
tCVEYXZpZCBKdW1hbmkgPGRhdmlkanVtYW5pQGFwYWNoZS5vcmc+iQJUBBMBCgA+
FiEEx+O0dyhjGqOfsCb8ktiOz01jySMFAmECVCwCGwMFCQPCZwAFCwkIBwIGFQoJ
CAsCBBYCAwECHgECF4AACgkQktiOz01jySMcMg/+LXbD1k0g+wyil+/CUzpeS4MB
pP0bRtRolY6T30AiN01NvMS3TPTOJmFdC0JOAkluWFL/SfHTvgVetVdE81GRYTyv
yzcDokSmQas1S5ldPw2p9Cmgp5MzgqZarxPXCkD26SSetsQmTVpa/jyjoKgw/Pha
Sb1pC8ZQogeH83koXJbiA5wY4lym30o6aMeZMDcRevUdOwwne5In9Ac1c5tnZ0cT
aZ8ou9Kb7X5/Wjm2eIbKuRxAy4yu31uKxbXtclyFdjA7K+vrUXFHtE1zQ8opd/DH
07Fqd9xSMwNcAlO4jlKZpFAtmHtLyr6aUjk0YyM4HNmV5y5jsmuUqHN5X3IhhoYr
aoj4JUXuDQTMJ4mksU2xIGIZm/kijZlMtcRWp/bqOwz9CeqrUGvgIrjMqG3puZYS
thUMiCu71/Iv0TrxpZPPLiRSkchkBbvif9HB/0Qh6x+Hg2knZz7YHEWcUa+CKV50
XpQjQh64WXjc6Hy4/NR2DOP6FXFnq5kqpOxL+uYeA4gPmf1cFtSEPjhkbJl1nS6K
/tJc0xqob5VIIKiVHAJreAMrvjk+XZPx5Rr7sB7YUyowO8cKKdoKrZ1IYgZh4ula
0CJp/FLuc5UnGYAUAAL8Z+0vIWJz7JIji+HBE1V0ipXvMBp5Cnw9TEyn06Sd7Y09
ogzHcVmW4B8oVEGSMH4=
=CBlM
-END PGP PUBLIC KEY BLOCK-


Thanks

From: Suresh Anaparti 
Sent: Thursday, July 15, 2021 8:45 PM
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Subject: Re: [PROPOSE] RM for CloudStack Kubernetes Provider v1.0

+1

Good luck David!

Regards,
Suresh

On 15/07/21, 12:02 PM, "David Jumani"  wrote:

Hi,

I'd like to put myself forward as the release manager for CloudStack 
Kubernetes Provider<https://github.com/apache/cloudstack-kubernetes-provider> 
v1.0.

This will be the first release of CloudStack Kubernetes Provider which 
facilitates Kubernetes deployments on Cloudstack.
It allows Kubernetes to dynamically allocate IP addresses and the 
respective networking rules on CloudStack to ensure seamless TCP, UDP and 
TCP-Proxy LoadBalancer deployments on Kubernetes.

It was initially the Cloudstack provider in Kubernetes which was later 
extracted to allow for pluggable providers.
A lot of work and effort has gone into developing it, and we are looking 
forward to its grand debut.

The list of open issues triaged for the v1.0 milestone can be found at 
https://github.com/apache/cloudstack-kubernetes-provider/milestone/1
If you encounter any issues, please do report them at 
https://github.com/apache/cloudstack-kubernetes-provider/issues

Looking forward to your support

Thanks,
David








 

Re: Code executed twice while deploying VM

[David Jumani]

Hi Rakesh,

If I'm right, that's because a VM can be deployed without starting it. It 
initially checks whether the VM can be deployed, and once again before starting 
as things might change (if started some time after deployment)
I'm all for optimizing the code but this is the reason I see the duplication of 
code / computation


From: Rakesh Venkatesh 
Sent: Wednesday, July 28, 2021 2:34 PM
To: users ; dev 
Subject: Code executed twice while deploying VM

Hello Users/Devs


Today I observed that while deploying a VM, the same code is executed
twice: the first time, while trying to find a suitable deployment
destination and the second time, while trying to start a VM. I think this
is a redundant process and also time-consuming since the same calculations
are done twice. These are the one of the duplicate logs

Asyn job is created
2021-07-28 09:01:27,964 (logid:10ac9f28) ZoneWideStoragePoolAllocator to
find storage pool

Now it finds a suitable destination
Returning Deployment Destination:
Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))]
: Dest[Zone(1)-Pod(1)-Cluster(1)-Host(1)-Storage(Volume(23|ROOT-->Pool(3))]

VM start attempt #1

2021-07-28 09:01:36,039 job-174/job-175 ctx-b815930d) (logid:10ac9f28)
ZoneWideStoragePoolAllocator to find storage pool


>From the above two logs, I can see that starting at 9:01:27 and 09:01:36,
its doing the same calculations.
if I see the logs before and after the above-mentioned logs, they are all
same. They try to find a suitable host, a suitable storage pool, and so on.
In the production platform, the calculation is done twice and this takes a
lot of time to deploy a VM.

Do you guys also think this is an issue or redundant process and needs to
be improved? Or any other suggestions to avoid double calculation?

--
Thanks and regards
Rakesh

 

[PROPOSE] RM for CloudStack Kubernetes Provider v1.0

[David Jumani]

Hi,

I'd like to put myself forward as the release manager for CloudStack Kubernetes 
Provider v1.0.

This will be the first release of CloudStack Kubernetes Provider which 
facilitates Kubernetes deployments on Cloudstack.
It allows Kubernetes to dynamically allocate IP addresses and the respective 
networking rules on CloudStack to ensure seamless TCP, UDP and TCP-Proxy 
LoadBalancer deployments on Kubernetes.

It was initially the Cloudstack provider in Kubernetes which was later 
extracted to allow for pluggable providers.
A lot of work and effort has gone into developing it, and we are looking 
forward to its grand debut.

The list of open issues triaged for the v1.0 milestone can be found at 
https://github.com/apache/cloudstack-kubernetes-provider/milestone/1
If you encounter any issues, please do report them at 
https://github.com/apache/cloudstack-kubernetes-provider/issues

Looking forward to your support

Thanks,
David

 

Re: [DISCUSS] Rocky 8.4 and CloudStack

[David Jumani]

Good idea Rohit, +1 on creating symlinks for el7, el8
I've also created a PR to support binary compatible variants of RHEL8. I'd 
appreciate feedback / testing from the community
I've tested it agianst Rocky & Alma and it seems to work just like C8 does

https://github.com/apache/cloudstack/pull/5158

From: Rohit Yadav 
Sent: Monday, June 28, 2021 4:32 PM
To: dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org 
Subject: Re: [DISCUSS] Rocky 8.4 and CloudStack

Great thanks all for the discussion, so what we mostly agree on are:

  *   CentOS8, Rocky Linux 8 and other initiatives may all be binary compatible
  *   We can host all el8 repos which these distros may use
  *   The community may help validate the CloudStack el8 pkgs among one or more 
clear winner with time

As an immediate action, let's us publish all "centos8" or "rocky8" package 
repos under generic "el8" repos? For example, 
http://download.cloudstack.org/testing/nightly/latest/ we can add symlink or 
rename dirs as "el8", "el7".


Regards.


From: n...@li.nux.ro 
Sent: Thursday, June 24, 2021 21:12
To: dev@cloudstack.apache.org 
Cc: Nathan McGarvey 
Subject: Re: [DISCUSS] Rocky 8.4 and CloudStack

That's a very good suggestion, I'm sure we can sort out something.

Regards,
Lucian





 

On 2021-06-24 14:40, Nathan McGarvey wrote:
> Nux,
> Also agree regarding EL8.
>
> I wonder if it is possible to build on a RHEL "development" license
> where builds and smoke tests and such can be done without licensing
> cost.
> (https://developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux,
> https://developers.redhat.com/terms-and-conditions)
>
> I'm not a lawyer and the terms seem murky as to how an Open-Source
> project like CloudStack would interact with those terms, even in a
> non-production sense. Do any other ASF projects use RHEL for build/test
> servers or anything like that?
>
>
> Thanks,
> -Nathan McGarvey
>
>
>
> On 6/24/21 8:17 AM, Sven Vogel wrote:
>> @nux
>>
>> „Might be then worth going for supporting "EL8" and by that include
>> any
>> of Rocky, Alma, OtherClone etc.“
>>
>> Agree
>>
>> __
>>
>> Sven Vogel
>> Senior Manager Research and Development - Cloud and Infrastructure
>>
>> EWERK DIGITAL GmbH
>> Brühl 24, D-04109 Leipzig
>> P +49 341 42649 - 99
>> F +49 341 42649 - 98
>> s.vo...@ewerk.com
>> www.ewerk.com
>>
>> Geschäftsführer:
>> Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
>> Registergericht: Leipzig HRB 9065
>>
>> Support:
>> +49 341 42649 555
>>
>> Zertifiziert nach:
>> ISO/IEC 27001:2013
>> DIN EN ISO 9001:2015
>> DIN ISO/IEC 2-1:2018
>>
>> ISAE 3402 Typ II Assessed
>>
>> EWERK-Blog |
>> LinkedIn |
>> Xing |
>> Twitter |
>> Facebook
>>
>>
>> Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
>>
>> Disclaimer Privacy:
>> Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien)
>> ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht
>> der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung,
>> Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte
>> informieren Sie in diesem Fall unverzüglich den Absender und löschen
>> Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem
>> System. Vielen Dank.
>>
>> The contents of this e-mail (including any attachments) are
>> confidential and may be legally privileged. If you are not the
>> intended recipient of this e-mail, any disclosure, copying,
>> distribution or use of its contents is strictly prohibited, and you
>> should please notify the sender immediately and then delete it
>> (including any attachments) from your system. Thank you.
>>
>> 
>> Von: n...@li.nux.ro 
>> Gesendet: Thursday, June 24, 2021 2:57:24 PM
>> An: dev@cloudstack.apache.org 
>> Betreff: Re: [DISCUSS] Rocky 8.4 and CloudStack
>>
>> Point taken. Good find with gdm, wonder if there are others.
>> I'm hoping this kind of problems disappear in time as the machine gets
>> "oiled" better.
>>
>> What I wanted to underline is that the situation is sort of like this:
>> Updates -> QA -> Stream -> RHEL
>>
>> Might be then worth going for supporting "EL8" and by that include any
>> of Rocky, Alma, OtherClone etc.
>>
>>
>>
>> On 2021-06-23 19:03, Nathan McGarvey wrote:
>>> Nux,
>>> Overall, I agree that it should be possible to use any other
>>> clone
>>> as they should be binary compatible.
>>>
>>> I don't quite understand your "pass through QA" and "basically
>>> RHEL
>>> packages" comment. There are already instances of breaking changes in
>>> CentOS 8 Stream that didn't make it into RHEL or CentOS non-stream.
>>> CentOS Stream is the only one where you *don't* know exactly what you

Re: Disabling a storage pool

[David Jumani]

You set it as readonly via the updateImageStore API

From: Rakesh Venkatesh 
Sent: Tuesday, June 29, 2021 7:14 PM
To: users ; dev 
Subject: Disabling a storage pool

Hello folks

Is there a way to disable a particular storage pool so that it won't be
used for further volume allocation? I don't want to enable the maintenance
mode as that will turn off the VM's whose volumes running on that pool. I
don't want to use a global setting also since this will come into effect
after the threshold value is reached.

In some cases even if the pool is just 10% allocated, I still want to
disable it so that the current volumes will keep existing on the same pool
and at the same time further deployment of volumes on this pool is disabled.

I looked at the storge tags options but that involves adding tags to
service offerings and I dont want to mess up with that tags. Should we add
a new api to enable this feature? or any other better suggestion?

--
Thanks and regards
Rakesh

 

Re: Error in hitting resetSSHKeyForVirtualMachine api

[David Jumani]

Hi Bikram,

In addition to what Rohit had mentioned, also go through 
https://github.com/shapeblue/hackerbook/blob/main/hack/db.md to ensure that the 
DAO is properly implemented so the query is generated correctly

From: Rohit Yadav 
Sent: Friday, June 25, 2021 3:45 PM
To: dev ; David Jumani 
Subject: Re: Error in hitting resetSSHKeyForVirtualMachine api

Hi Bikram,

(FYI - Bikram is our GSoC21 [1] student, cc @David 
Jumani<mailto:david.jum...@shapeblue.com> primary mentor)

  *   Are you hitting this on the latest main​ branch?
  *   Is the ssh key registered in the DB a valid SSH key and are you testing 
this using Simulator or KVM (or something else)?
  *   Is the keypairs parameter something you've introduced as part of your 
project? Is it handled properly at the API implement (refer 
https://github.com/shapeblue/hackerbook/blob/main/hack/api.md#introduction)

[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/GSoC+2021


Regards.

Rohit Yadav
Principal Engineer
rohit.ya...@shapeblue.com
www.shapeblue.com








From: Daan Hoogland 
Sent: Friday, June 25, 2021 13:19
To: dev 
Subject: Re: Error in hitting resetSSHKeyForVirtualMachine api

Bikram,
I see and extra parameter "keypairs" that would not be recognised and hence
ignored but otherwise your cli seem correct according to [1]

I think you hit a bug, please investigate the logs and create an issue at
[2] if you feel it is a  cloudstack issue or at [3] if it is a cmk issue

[1]
http://cloudstack.apache.org/api/apidocs-4.15/apis/resetSSHKeyForVirtualMachine.html
[2] https://github.com/apache/cloudstack/issues/new/choose
[3] https://github.com/apache/cloudstack-cloudmonkey/issues/new/choose

regards,

On Fri, Jun 25, 2021 at 9:01 AM Bikram Biswas 
wrote:

> Here is the command and message in cloudmonkey. The VM is connected with
> the ssh-key-pair with the name 'myname'
>
> (bicrxm)  > reset sshkeyforvirtualmachine account=admin
> domainid=a7509cc5-d50e-11eb-afe0-646e69d9cd09 keypair=myname
> id=c9e37866-2314-46f8-8741-9b2d045ad40a keypairs=myname
> {
>   "accountid": "a751fb3a-d50e-11eb-afe0-646e69d9cd09",
>   "cmd":
> "org.apache.cloudstack.api.command.admin.vm.ResetVMSSHKeyCmdByAdmin",
>   "completed": "2021-06-25T12:24:47+0530",
>   "created": "2021-06-25T12:24:45+0530",
>   "jobid": "53db8eca-cf4c-4eb6-a9f2-a37d54af0f7d",
>   "jobinstanceid": "c9e37866-2314-46f8-8741-9b2d045ad40a",
>   "jobinstancetype": "VirtualMachine",
>   "jobprocstatus": 0,
>   "jobresult": {
> "errorcode": 530,
> "errortext": "Caught: com.mysql.cj.jdbc.ClientPreparedStatement:
> SELECT ssh_keypairs.id, ssh_keypairs.account_id, ssh_keypairs.domain_id,
> ssh_keypairs.keypair_name, ssh_keypairs.fingerprint,
> ssh_keypairs.public_key FROM ssh_keypairs WHERE ssh_keypairs.account_id =
> 2  AND ssh_keypairs.domain_id = 1  AND ssh_keypairs.keypair_name = ** NOT
> SPECIFIED **  ORDER BY ssh_keypairs.keypair_name DESC "
>   },
>   "jobresultcode": 530,
>   "jobresulttype": "object",
>   "jobstatus": 2,
>   "userid": "a781b145-d50e-11eb-afe0-646e69d9cd09"
> }
>  Error: async API failed for job 53db8eca-cf4c-4eb6-a9f2-a37d54af0f7d
> (bicrxm)  >
>
>

--
Daan

 

Re: [DISCUSS] Rocky 8.4 and CloudStack

[David Jumani]

+1
I think that since Cenots8 / Rocky / Alma are binary compatible it would be 
sufficient to support Rocky since it is looking like the go to alternative, and 
supporting any one would pretty much be supporting the other
About dropping support, I'm for supporting it until EOL this year

From: Rohit Yadav 
Sent: Tuesday, June 22, 2021 1:11 PM
To: dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org 
Subject: [DISCUSS] Rocky 8.4 and CloudStack

All,

With GA release of Rocky Linux 8.4 
(https://docs.rockylinux.org/release_notes/8.4) does it make sense now to 
completely drop support for CentOS8 in the next major release? I did a quick 
test and it seems rpms built on centos8 container continue to work on Rocky 
release. Thoughts?

Regards,
Rohit Yadav




 

OpenSUSE Support

[David Jumani]

Hi,

Hope you are all doing well.

I'm currently working on adding support for openSUSE Leap 15.2+ as a KVM 
hypervisor and Management / Usage server for Cloudstack,
I've raised a draft PR (still a WIP) and would like to get feedback and your 
thoughts on the idea as well as the code
https://github.com/apache/cloudstack/pull/5110
TIA

 

Re: Nightly builds availability

[David Jumani]

Thanks for that Wei, I'll make the changes to the deb packages

From: Wei ZHOU 
Sent: Friday, May 14, 2021 12:41 PM
To: dev@cloudstack.apache.org 
Subject: Re: Nightly builds availability

Nice Rohit !

I notice that the name of packages for debian do not contain the date or
timestamp, would it be better to use "./build-deb.sh -T" ?

-Wei


 

On Thu, 13 May 2021 at 12:14, Rohit Yadav  wrote:

> All,
>
> Many users in emails, issues and PRs have asked for packages or suggested
> that they'll help test a particular fix after release packages are
> available.
>
> To facilitate users with developer or snapshot builds of latest branches
> of Apache CloudStack, we've setup a daily build job also popularly called
> "nightly" builds [1]:
> https://download.cloudstack.org/testing/nightly
>
> The nightly builds will include the two most recent development branches,
> for example the master/main branch (4.16.0.0-snapshot) and the 4.15 branch
> (4.15.1.0-snapshot), built from https://github.com/apache/cloudstack
>
> Only last seven builds will be kept in the above location, users may help
> test CloudStack by using the latest developer/snapshot build using:
> https://download.cloudstack.org/testing/nightly/latest/
>
> Systemvmtemplates are available here that will work for nightly builds:
> https://download.cloudstack.org/systemvm/
>
> NOTE: upgrade paths will NOT be supported or maintained for these
> developer/snapshot builds, therefore users shouldn't use this in
> production. A fresh installation of these builds are recommended in your
> testing effort.
>
> With this I invite all contributors to help us test the 4.15 branch
> towards the 4.15.1.0 (RC1 to be cut tentatively b/w 24-31 May 2021):
> https://download.cloudstack.org/testing/nightly/latest/centos7/4.15/
> https://download.cloudstack.org/testing/nightly/latest/centos8/4.15/
> https://download.cloudstack.org/testing/nightly/latest/debian/4.15/
> https://download.cloudstack.org/systemvm/4.15/ (use the 4.15.1
> systemvmtemplate)
>
> [1] https://en.wikipedia.org/wiki/Daily_build
>
>
> Regards.
>
>
>
>

Re: [VOTE] Renaming default git branch name from 'master' to 'main' and replace offensive words as appropriate for inclusiveness

[David Jumani]

+1
However I think it's better to rename it to leader / worker rather than primary 
/ secondary in the case of resources that follow such a paradigm like 
kubernetes, etc

From: Suresh Anaparti 
Sent: Friday, April 30, 2021 5:13 PM
To: dev@cloudstack.apache.org ; 
priv...@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: [VOTE] Renaming default git branch name from 'master' to 'main' and 
replace offensive words as appropriate for inclusiveness

Hi All,

Following the discussion thread on renaming default git branch name and 
inclusiveness [1], I would like to start a vote to gather consensus on the 
following plan:

1. Accept the following rename PRs (raised against 'master' branch) which 
renames git default branch to 'main' and replaces some offensive words, and 
Merge them post acceptance.
- cloudstack => PR: https://github.com/apache/cloudstack/pull/4922
- cloudstack-documentation => PR: 
https://github.com/apache/cloudstack-documentation/pull/155
- cloudstack-www => PR: https://github.com/apache/cloudstack-www/pull/83
- cloudstack-cloudmonkey => PR: 
https://github.com/apache/cloudstack-cloudmonkey/pull/76
- cloudstack-kubernetes-provider => PR: 
https://github.com/apache/cloudstack-kubernetes-provider/pull/29
- cloudstack-ec2stack => PR: 
https://github.com/apache/cloudstack-ec2stack/pull/2
- cloudstack-gcestack => PR: 
https://github.com/apache/cloudstack-gcestack/pull/3

2. Request ASF infra to disable pushes to 'master' branch.

3. Rename 'master' branch to 'main' [2][3], and Request ASF infra (open INFRA 
ticket) to make 'main' as the default branch [4], in GitHub repo settings for 
all the CloudStack repos. This will also re-target the current PRs against 
'master' branch to 'main'.

3a. The update on the central repo will be done as follows (only by a PMC or 
Infra member with access)
- Clone the repo (git clone https://github.com/apache/cloudstack.git)
- Sync local 'master' with the cloudstack repo (cd cloudstack && git 
checkout master && git fetch --all -p && git pull)
- Rename local 'master' branch to 'main' (git branch -m master main)
- Push renamed 'main' branch (git push -u origin main)
- Update Default Branch on GitHub [4]
- Delete 'master' branch (git push origin --delete master)
3b. After the central renaming has been done. New users can clone and directly 
checkout 'main' branch. Existing users can start using 'main' locally, using 
the below steps.
- Switch to master branch (git checkout master)
- Rename local 'master' branch to 'main' (git branch -m master main)
- Sync local 'main' with repo (git fetch)
- Remove the existing tracking connection with “origin/master” (git 
branch --unset-upstream)
- Create a new tracking connection with the new “origin/main” branch 
(git branch -u origin/main)
- All local branches should still point to the same commit as base 
revision. If there is a problem (git checkout  && git 
rebase main)

4. Update the integrated systems with CloudStack repos, mainly Travis CI and 
Jenkins configuration with 'main' branch. Check and update UI building, 
apidocs, systemvmtemplate builds; project website and docs (cwiki); and any 
other build/release jobs. Track them through the issue: 
https://github.com/apache/cloudstack/issues/4887.

5. Perform Health Checks (using a dummy PR), and ensure there are no issues 
with the build/release configuration. This PR needs to run full matrix of 
tests. Fix the issues noticed during the health checks.

6. Announce the default branch change to 'main' (and 'master' deprecation) on 
the mailing list.

The vote will be open until Fri 7th May 2021.

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

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

[1] https://markmail.org/message/k767evgjnmzogyhf
[2] https://github.com/github/renaming
[3] 
https://docs.github.com/en/github/administering-a-repository/renaming-a-branch
[4] 
https://docs.github.com/en/github/administering-a-repository/changing-the-default-branch

Regards,
Suresh





 

Missing Features in the new UI

[David Jumani]

Hi,

I was going through the new UI and noticed that a few features are not yet 
implemented in the new UI which exist in the legacy UI and APIs exist in the 
backend (not sure whether they're still functional). I've made a list of them 
over at https://github.com/apache/cloudstack/issues/4937 and wanted to get 
feedback on whether there's a need or sufficient users who still use them to 
implement them in the new UI. The primary ones are :
  *

  *   Global Server Load Balancing Support 
http://docs.cloudstack.apache.org/en/latest/adminguide/networking/global_server_load_balancing.html
  *   AutoScale without Netscaler 
http://docs.cloudstack.apache.org/en/latest/adminguide/autoscale_without_netscaler.html
  *   Override default traffic label for VMware with nexus / dvswitch when 
adding a cluster

If anyone is still using them, please shoutout so a call can be taken whether 
to implement them in the new UI or not



 

Re: multiple SSH keys. Question to the dev community members

[David Jumani]

Hi Bikram,

That's a good idea.
I think it would benefit the users by allowing them to add their own personal 
SSH key to a VM and avoid the hassle of managing multiple shared keys for 
different VMs (across projects / domains). It also solves the problem when a 
user is removed as their key can be removed from the list, revoking their 
access without the need for a new key to be regenerated and shared. It could 
also simplify monitoring as well as automation from a central server to the VMs 
in the infrastructure without additional steps of using a specific key per VM 
or group of VMs

From: Bikram Biswas 
Sent: Saturday, April 10, 2021 7:28 PM
To: dev@cloudstack.apache.org 
Subject: multiple SSH keys. Question to the dev community members

Hi Dev community.
I want to start a discussion thread about multiple-SSH key support.
Currently, ACS supports only a single ssh key. What do you think about the 
benefits of holding multiple ssh keys. How can it help the community and the 
users, if the support for multiple ssh keys is provided?

david.jum...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 

Re: Overprovisioning consideration in metrics API response

[David Jumani]

+1 on this. Allocated should consider overprovisioning!

From: Rohit Yadav 
Sent: Wednesday, March 31, 2021 3:30 PM
To: dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org 
Subject: Re: Overprovisioning consideration in metrics API response

Thanks for starting this thread Abhishek. I think all 'allocated' API response 
keys (irrespective of type such as CPU, RAM, storage/disk etc) across all 
list/metrics APIs should consider overprovisioning factor.

For example, if the total resource value/limit is 100 and overprovisioning 
factor is 1.5 that means CloudStack can effectively allocate 1.5*100=150 of 
that resource, which in actual or physical value is (allocated value / 
over-provisioning factor). Let me add user@ ML to hear if users agree with my 
interpretation of allocated values/metrics.


Regards.


From: Abhishek Kumar 
Sent: Wednesday, March 31, 2021 13:31
To: dev@cloudstack.apache.org 
Subject: Overprovisioning consideration in metrics API response

Hi devs,

There have been recurring issues and changes for API responses not considering 
the over-provisioning factor while reporting metrics for hosts, clusters, etc.
https://github.com/apache/cloudstack/issues/4778
https://github.com/apache/cloudstack/pull/4850
https://github.com/apache/cloudstack/pull/4499

While some of the metric parameters doesn't consider overprovisioning at all, 
some give value in the format- "memorytotalgb": "6.78 GB (x 1.0)".​
So, to address this should we consider a code/API-wide change?
And while fixing it should we introduce new parameters such as - 
cputotalwithoverprovisioning, memorytotalwithoverprovisioning, etc or should we 
apply the overprovisioning factors to the existing response parameters?
Please share your thoughts.

Regards,
Abhishek

abhishek.ku...@shapeblue.com
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue




rohit.ya...@shapeblue.com
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue




david.jum...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 

Re: [DISCUSS] Marvin tests interaction

[David Jumani]

+1 on the idea and on Rakesh's suggestions!

From: Rakesh v 
Sent: Monday, March 29, 2021 11:50 PM
To: dev@cloudstack.apache.org 
Subject: Re: [DISCUSS] Marvin tests interaction

I have added my thoughts in the issue link. Hope that's useful to you.

Sent from my iPhone


david.jum...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 

> On Mar 29, 2021, at 4:51 AM, Nicolas Vazquez  
> wrote:
>
> Hi,
>
> I would like to propose an idea to improve the interaction with the marvin 
> tests through the management server. This could be useful for development and 
> test environments in which tests could be easily started, configured and 
> their results monitored through the UI.
>
> This could be achieved by creating a new service in charge of the execution 
> of the tests and sending results back to the management server, so it can 
> display them. A more detailed description: 
> https://github.com/apache/cloudstack/issues/4799
>
> I would like to hear your thoughts and ideas about it. Would you find this 
> useful?
>
>
> Regards,
>
> Nicolas Vazquez
>
> nicolas.vazq...@shapeblue.com
> www.shapeblue.com
> 3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
> @shapeblue
>
>
>

Re: update - Google Summer of Code 2021

[David Jumani]

Thanks Bobby!
+1

From: Boris Stoyanov 
Sent: Friday, March 19, 2021 11:14 AM
To: dev@cloudstack.apache.org 
Subject: Re: update - Google Summer of Code 2021

Hi all,

I’ve created a separate ticket in JIRA with title prefix GSoC 2021 and labels: 
‘gsoc2021’,’mentor’. This will allow it to be picked up automatically and added 
to the page that Maxim created.

I encourage everyone who submitted idea to advertise it in the same manner so 
it can stand out with other ideas on this huge page.

Bobby.

From: Rohit Yadav 
Date: Friday, 19 March 2021, 7:29
To: dev@cloudstack.apache.org 
Subject: Re: update - Google Summer of Code 2021
Thanks for following up Giles, I've subscribed to the mentors@ ML and got 
invited as a mentor on the GSoC portal after sending/receiving ack request on 
mentors@ and priv...@cloudstack.apache.org.

There seems to be some issue in wiki generation and I working with Maxim from 
mentors@ to be our list republished.

Regards.

Regards,
Rohit Yadav


From: Giles Sirett 
Sent: Wednesday, March 17, 2021 9:53:47 PM
To: dev@cloudstack.apache.org 
Subject: update - Google Summer of Code 2021

All
Just an update on where the project is with GSoC


We've had a number of suggestions on this mailing list and also some people 
submitting ideas as Github issues:
https://github.com/apache/cloudstack/issues?q=is%3Aissue+is%3Aopen+label%3Agsoc2021

Thank you everybody who has submitted a project and said you'd act as a mentor



Below, I've collated all of the proposed  ideas (abbreviated project names)

Harikrishna "mapping existing configuration parameters to the APIs"
Suresh "Cloning a Virtual Machine (with all the data disks)"
Boris "improvements in the UI around user experience. navigate around just 
using keyboards"
David  "allowing the user to set multiple SSH keys"
Alireza  "writing a Container Storage Interface (CSI) for Kubernetes"
Daan: suggested a number of projects but unfortunately isn't able to mentor 
this year.
Rohit "onboard users with existing XenServer/VMware/* environments with VMs to 
CloudStack/KVM."
Pearl "extending the behaviour of Persistent Networks in CloudStack."
Wei "Spice console"
Nicolas initially put forward "marvin test service"  but has since contacted me 
to say  that he'd prefer to put forward on of Daans projects: "authentication 
plugins for public authentication providers like google/microsoft/facebook/etc"


I think these all look like interesting projects

@ Alireza   - as far as I can see from discussions on list, your initial idea 
didn't seem to develop into a proposal. Do you still wish to pursue it ?

WHAT PROPOSERS NOW NEED TO DO==

We have two primary things to do to make these available as Apache GSoC 
projects:


  1.  We need to get them listed on COMDEV here:
https://cwiki.apache.org/confluence/display/COMDEV/GSoC+2021+Ideas+list#GSoC2021Ideaslist-CloudStack

This is the page that students will visit if they choose to browse  Apache as a 
partner (Thanks to Rohit for getting the initial CloudStack listing here)

Note: we will be competing with other projects for the students attention, so 
need to ensure that the listings are "attractive"

My thinking is that the descriptions need to be more "student focussed" - i.e 
they cannot assume any CloudStack knowledge and they should explain the type of 
tech/skills involved
Could I therefore ask everybody to reply to this thread with a more structured 
project description:

- project Title

-brief description including what problem this solves & what are its benefits
-technologies involved (i.e. Java, VueJS)
-who would this suit ? (i.e. this would suit somebody with a passion for UI 
design)

I will then take those descriptions and add them to our listing on COMDEV


  1.  Mentors need to read https://community.apache.org/gsoc.html and, 
specifically,  register with the mailing list 
ment...@community.apache.org ASAP
They should then get an invite from the GSoC people. Being on this list allows 
you to be officially recognised as a mentor but also to help deal with any 
student enquiries about your projects


===

Kind regards
Giles


giles.sir...@shapeblue.com
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue




rohit.ya...@shapeblue.com
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue



boris.stoya...@shapeblue.com
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue




david.jum...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 

Re: Congratulations to Sven - Apache Software Foundation Member

[David Jumani]

Congratulations Sven!

From: Paul Angus 
Sent: Thursday, March 18, 2021 2:43 AM
To: dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org 
Subject: Congratulations to Sven - Apache Software Foundation Member

Hi All,



More great news.



Please join me in congratulating Sven,  for being made a Member of the
Apache Software Foundation.



Congratulations Sven, keep up the good work!



Kind regards



Paul Angus




david.jum...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 

Re: Congratulations to Gabriel - CloudStack PMC Chair

[David Jumani]

Congratulations Gabriel !

From: Paul Angus 
Sent: Thursday, March 18, 2021 2:40 AM
To: dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org 
Cc: priv...@cloudstack.apache.org 
Subject: Congratulations to Gabriel - CloudStack PMC Chair

Hi All CloudStack enthusiasts!



Please join me in congratulating Gabriel for becoming the next CloudStack
PMC Chair.

Congratulations Gabriel, very well deserved!



I would also like to thank Sven for his great work of the past year!







Kind regards



Paul Angus




david.jum...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 

Re: Goggle Summer of Code 2021

[David Jumani]

Hi Boris,

+1 on the idea and I'm happy to co-mentor wrt the coding part

From: Boris Stoyanov 
Sent: Monday, March 15, 2021 1:07 PM
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org ; 
priv...@cloudstack.apache.org 
Subject: Re: Goggle Summer of Code 2021

Hi Giles and all,

I’d like to propose some improvements in the UI around user experience. I think 
it’ll be great if users can navigate around just using keyboards, meaning go to 
different pages, confirm dialogues and submit forms without the use of mouse.

Here’s a detailed description of the feature: 
https://github.com/apache/cloudstack/issues/4798

As far as mentorship, I’m happy to take part on the ideas/requirements side of 
the feature, but we’ll need a volunteer for the coding part.

Thanks,
Bobby.

From: Giles Sirett 
Date: Tuesday, 16 February 2021, 11:30
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org , 
priv...@cloudstack.apache.org 
Subject: Goggle Summer of Code 2021
Hi all

It would be great if the CloudStack project were able to get a few Google 
Summer of Code  [1] students this year to work on projects within our 
community. We've had a number of previous GSoC students (examples at [2] ), who 
have worked on innovative features/ projects within cloudstack and have then 
gone on to become significant contributors to Cloudstack .


In order to be able to attract students to work on Cloudstack, we need 2 things:

  1.  A number of candidate projects for students to work on. Students browse 
all GSoC the candidate projects and choose one that interests them- effectively 
every organisation is competing for the students interest.  These projects 
therefore need to be reasonably interesting looking projects to attract 
potential students. The students spend approximately 9 weeks coding, so the 
projects need to be appropriately scaled
  2.  Somebody prepared to mentor the student throughout the duration of the 
project (usually the person who suggests the project)

The student application period starts 29 March [3]
The ASF  has registered itself as a mentor  organisation with Google , allowing 
individual Apache projects to list candidate projects  for students to work on. 
A wiki page [4]  has been created at the ASF level to allow ASF projects to  
list their ideas for students


I'm happy to coordinate this from a Cloudstack perspective.
If others are happy with this approach, then I ask for two things at this stage:


  1.  Could people suggest appropriate projects. This could be a piece of 
integration that you've always considered and not got around to or could be an 
improvement that you've always wanted to do. If people can reply to this thread 
with ANY ideas, it would be a good start (irrespective of whether you wish to 
be a mentor or not)
  2.  At the same time, could people say whether they'd be prepared to be a 
student mentor or not




[1] https://summerofcode.withgoogle.com/


[2]
https://blog.netapp.com/blogs/mentoring-with-google-summer-of-code-and-lessons-in-cloudstack/
https://dzone.com/articles/cloudstack-google-summer-code
https://opensource.googleblog.com/2014/07/gsoc-students-create-google-compute.html


[3]https://summerofcode.withgoogle.com/how-it-works/#timeline

[4] https://cwiki.apache.org/confluence/display/COMDEV/GSoC+2021+Ideas+list



Kind regards
Giles


giles.sir...@shapeblue.com
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue



boris.stoya...@shapeblue.com
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue




david.jum...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 

Re: Goggle Summer of Code 2021

[David Jumani]

Hi,

I'd like to propose the idea of allowing the user to set multiple SSH keys for 
a VM rather than just a single one via the API.
It would be simple enough to complete within the timeframe for someone new to 
the project as well as be a great addition to ACS

Thanks,
David

From: Giles Sirett 
Sent: Tuesday, February 16, 2021 2:59 PM
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org ; 
priv...@cloudstack.apache.org 
Subject: Goggle Summer of Code 2021

Hi all

It would be great if the CloudStack project were able to get a few Google 
Summer of Code  [1] students this year to work on projects within our 
community. We've had a number of previous GSoC students (examples at [2] ), who 
have worked on innovative features/ projects within cloudstack and have then 
gone on to become significant contributors to Cloudstack .


In order to be able to attract students to work on Cloudstack, we need 2 things:

  1.  A number of candidate projects for students to work on. Students browse 
all GSoC the candidate projects and choose one that interests them- effectively 
every organisation is competing for the students interest.  These projects 
therefore need to be reasonably interesting looking projects to attract 
potential students. The students spend approximately 9 weeks coding, so the 
projects need to be appropriately scaled
  2.  Somebody prepared to mentor the student throughout the duration of the 
project (usually the person who suggests the project)

The student application period starts 29 March [3]
The ASF  has registered itself as a mentor  organisation with Google , allowing 
individual Apache projects to list candidate projects  for students to work on. 
A wiki page [4]  has been created at the ASF level to allow ASF projects to  
list their ideas for students


I'm happy to coordinate this from a Cloudstack perspective.
If others are happy with this approach, then I ask for two things at this stage:


  1.  Could people suggest appropriate projects. This could be a piece of 
integration that you've always considered and not got around to or could be an 
improvement that you've always wanted to do. If people can reply to this thread 
with ANY ideas, it would be a good start (irrespective of whether you wish to 
be a mentor or not)
  2.  At the same time, could people say whether they'd be prepared to be a 
student mentor or not




[1] https://summerofcode.withgoogle.com/


[2]
https://blog.netapp.com/blogs/mentoring-with-google-summer-of-code-and-lessons-in-cloudstack/
https://dzone.com/articles/cloudstack-google-summer-code
https://opensource.googleblog.com/2014/07/gsoc-students-create-google-compute.html


[3]https://summerofcode.withgoogle.com/how-it-works/#timeline

[4] https://cwiki.apache.org/confluence/display/COMDEV/GSoC+2021+Ideas+list



Kind regards
Giles


giles.sir...@shapeblue.com
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue




david.jum...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 

Re: [DISCUSS] python test framework

[David Jumani]

++1 and like Boris said, need to look into backward compatibility

From: Boris Stoyanov 
Sent: Thursday, November 12, 2020 2:26 PM
To: dev@cloudstack.apache.org 
Subject: Re: [DISCUSS] python test framework

+1 on nose2, as the marvin plugin is built on nose, it seems the natural choice 
to upgrade to. We need to investigate backwards compatibility though..

Bobby.

On 11.11.20, 21:28, "Daan Hoogland"  wrote:

devs,
Investigating an new organization of test categories , I found that our 
framework in use, nose, is no longer in maintenance. Its maintainer has stopped 
his support in 2017. As it is quite stable it has slipped our attention, but it 
is urgent that we discuss and choose a way forward. There is a successor, 
nose2, which as the documentation tells me, has less support for underlying 
test types but is also extensible. This is my goto choice to investigate 
further the coming days, but I’d like input from of you as many as possible.
Regards,

daan.hoogl...@shapeblue.com
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue





boris.stoya...@shapeblue.com
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue




david.jum...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 

Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support

[David Jumani]

Right now I've gone with the approach of creating a user in the cluster owner's 
account with the suffix '-kubeadmin'. That way api permissions won't be an 
issue and neither will a globally set api key and secret cause security 
loopholes.
It seems the simplest and meets the consensus of the discussion

From: Paul Angus 
Sent: Thursday, November 5, 2020 4:07 PM
To: dev@cloudstack.apache.org 
Subject: RE: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support

I'm thinking about the way Accounts work.  You could add users to the account, 
but their usernames would have to be unique. So an existing user would need 
another (different) username in the service account.

We're doing work on projects, where users (not accounts) can be members and 
have different roles in different projects.  It may be possible to have a 
service 'project' with already existing users, but I've not tried it.





paul.an...@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue




david.jum...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 


-Original Message-
From: Sven Vogel 
Sent: 13 October 2020 12:06
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support

Should it possible to grant other users the control about the service user?


__

Sven Vogel
Lead Cloud Solution Architect

EWERK DIGITAL GmbH
Brühl 24, D-04109 Leipzig
P +49 341 42649 - 99
F +49 341 42649 - 98
s.vo...@ewerk.com
www.ewerk.com<http://www.ewerk.com>

Geschäftsführer:
Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
Registergericht: Leipzig HRB 9065

Support:
+49 341 42649 555

Zertifiziert nach:
ISO/IEC 27001:2013
DIN EN ISO 9001:2015
DIN ISO/IEC 2-1:2011

ISAE 3402 Typ II Assessed

EWERK-Blog<https://blog.ewerk.com/> | 
LinkedIn<https://www.linkedin.com/company/ewerk-group> | 
Xing<https://www.xing.com/company/ewerk> | 
Twitter<https://twitter.com/EWERK_Group> | 
Facebook<https://de-de.facebook.com/EWERK.IT/>


Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.

Disclaimer Privacy:
Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist 
vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der 
bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, 
Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte 
informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die 
E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen 
Dank.

The contents of this e-mail (including any attachments) are confidential and 
may be legally privileged. If you are not the intended recipient of this 
e-mail, any disclosure, copying, distribution or use of its contents is 
strictly prohibited, and you should please notify the sender immediately and 
then delete it (including any attachments) from your system. Thank you.


Von: Paul Angus 
Gesendet: Tuesday, October 13, 2020 1:00:54 PM
An: dev@cloudstack.apache.org 
Betreff: RE: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support

In the release notes for the old CCS we strongly recommended that the user 
created a service account or at least a service 'user'. Ultimately it has to be 
on the user to control 'who' can do what.


paul.an...@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK @shapeblue




-Original Message-
From: David Jumani 
Sent: 13 October 2020 11:39
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support

Thanks Daan. Users within the same account can alter the cluster, so I'm 
thinking of a service user within the same account and use the service user's 
keys. This will also prevent any mess up if the user provides his keys and then 
later regenerates them.

From: Daan Hoogland 
Sent: Tuesday, October 13, 2020 3:28 PM
To: dev 
Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support

That is a good question. Is the user going to be the only user responsible for 
messing up the k8 cluster, or will other users be able to as well? For 
convenience and if audit is to not lay false balme on a user, I'd say create a 
system/service account, if several users can mess up each other with it... 
makes sense?

On Tue, Oct 13, 2020 at 11:10 AM David Jumani 
wrote:

> Sounds good. And do you think it would be better to have the user
> provide the API keys or create a service account and use its keys?
> 
> From: Daan Hoogland 
> Sent: Monday, October 12, 2020 6:28 PM
> To: dev 
> Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler
> su

Re: New Joiner

[David Jumani]

Welcome Hoang!

Thanks,
David

From: Unitech Mai Nguyen 
Sent: Wednesday, November 4, 2020 8:01 AM
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Cc: sven.vo...@qform.de 
Subject: New Joiner

Hello Everyone,

My name is Hoang and I'm currently working for Ewerk.
It is my great pleasure to have a chance to join the Cloudstack Primate project.
It has been a wonderful time for me since last December when I started my first 
task.

I would look forward to being a part of this team for a long time to go. And I 
hope to have your kind help.
Thank you so much.
__
Hoang Nguyen
Frontend Developer

EWERK DIGITAL GmbH
Brühl 24, D-04109 Leipzig
P +49 341 42649 - 99
F +49 341 42649 - 98
www.ewerk.xn--com-zq0a

Geschäftsführer:
Dr. Erik Wende, Hendrik Schubert, Frank Richter
Registergericht: Leipzig HRB 9065

Zertifiziert nach:
ISO/IEC 27001:2013
DIN EN ISO 9001:2015
DIN ISO/IEC 2-1:2011

__

Unitech Mai Nguyen
Frontend Developer

EWERK DIGITAL GmbH
Brühl 24, D-04109 Leipzig
P
F +49 341 42649 - 98
hoang.ngu...@ewerk.com
www.ewerk.com

Geschäftsführer:
Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
Registergericht: Leipzig HRB 9065

Support:
+49 341 42649 555

Zertifiziert nach:
ISO/IEC 27001:2013
DIN EN ISO 9001:2015
DIN ISO/IEC 2-1:2011

ISAE 3402 Typ II Assessed

EWERK-Blog | 
LinkedIn | 
Xing | 
Twitter | 
Facebook


Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.

Disclaimer Privacy:
Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist 
vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der 
bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, 
Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte 
informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die 
E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen 
Dank.

The contents of this e-mail (including any attachments) are confidential and 
may be legally privileged. If you are not the intended recipient of this 
e-mail, any disclosure, copying, distribution or use of its contents is 
strictly prohibited, and you should please notify the sender immediately and 
then delete it (including any attachments) from your system. Thank you.

david.jum...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 

Re: Triage Permission

[David Jumani]

Hi All,

A big thanks to everyone who supported this idea. It's working out quite well 
allowing community members contribute further.
I'd like to suggest that others who would like the triage permission to boldly 
request it. It requires community / PMC approval followed by an infra ticket 
raised on the apache Jira, similar to this 
https://issues.apache.org/jira/browse/INFRA-20855
Request and approval can be gotten by shooting out a mail mentioning your 
GitHub handle in the mailing list, preferably as part of this mail chain to 
make it easier to pass on a consolidated to the infrastructure team to reduce 
complications and to speed up the process.

Thanks and happy Triaging!
David

From: Paul Angus 
Sent: Monday, September 21, 2020 3:11 PM
To: dev@cloudstack.apache.org 
Subject: RE: Triage Permission

Speaking with my Apache Member's hat on, the Apache ethos is to try to 'police' 
things through social controls rather than technically.

This exact topic has been discussed at Members level, and this (above) is the 
current consensus.  [sorry I'm not at liberty to share Member's email chains].  
However, this hasn't been ratified as an 'official' position, so infra are 
understandably playing it safe and only giving permissions to named people who 
have asked and been granted permission by the relevant project.

You can see this being actioned by infra here for another project:
https://issues.apache.org/jira/browse/INFRA-20853?jql=project%20%3D%20INFRA%20AND%20text%20~%20%22triage%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

[CloudStack hat back on]

I am massive +1 on removing a barrier to people's participation.  And whatever 
controls are eventually deemed appropriate, I'm petty Zen about.


Paul

paul.an...@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue




david.jum...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 


-Original Message-
From: Daan Hoogland 
Sent: 21 September 2020 10:18
To: dev 
Subject: Re: Triage Permission

In general, I'm fine with giving karma to any user on request for those 
abilities. I don't think a trial for a limited set of users makes sense.
And I don't think the PMC or committers will be able to control and revert on 
abuse. we'll need infra for both awarding and retracting.

On Mon, Sep 21, 2020 at 11:05 AM David Jumani 
wrote:

> Hi,
>
> While working with the CloudStack repository, logging issues and
> contributing, I've noticed a long turnaround time for issues and pull
> requests. I guess that it might have to do with the fact that only
> committers can modify and manage them.
> To alleviate this, I'd like to propose the granting the Triage
> permission<
> https://docs.github.com/en/github/setting-up-and-managing-organization
> s-and-teams/repository-permission-levels-for-an-organization>
> on GitHub to some of the active members of our community.
>
>
> They can manage issues / pull requests, and add bots to automate
> mundane tasks, without having write access to the repository.
> This would be a great stepping stone for growing the community,
> reducing the workload on Committers and would help in keeping
> community members and developers engaged in the project!
>
> As a trial, I'd propose the following users be granted it and based on
> the result / feedback we can continue to add more members @shwstppr
> @davidjumani @Pearl1594 @ACSGitBot @Spaceman1984 @sureshanaparti
> @vladimirpetrov
>
> Thanks,
> David
>
>
> david.jum...@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
> @shapeblue
>
>
>
>

--
Daan

Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support

[David Jumani]

A service account with only access to the listKubernetesCluster and 
scaleKubernetesCluster should work.
But to prevent a single API key from being used to mess with all the clusters, 
multiple users within the service account, mapping to each account which has a 
cluster with autoscaling enabled will need to be created. This might add 
additional complexity.
How about asking the user to provide API keys instead (or generating them if 
not already created) ?

From: Sven Vogel 
Sent: Wednesday, October 14, 2020 2:45 AM
To: dev@cloudstack.apache.org 
Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support

Maybe RBAC this is not a bad idea so  it’s possible to grant different 
permissions to users or the service user.


Von: Rakesh v http://www.rakeshv@gmail.com>>

__

Sven Vogel
Lead Cloud Solution Architect

EWERK DIGITAL GmbH
Brühl 24, D-04109 Leipzig
P +49 341 42649 - 99
F +49 341 42649 - 98
s.vo...@ewerk.com
www.ewerk.com<http://www.ewerk.com>

Geschäftsführer:
Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
Registergericht: Leipzig HRB 9065

Support:
+49 341 42649 555

Zertifiziert nach:
ISO/IEC 27001:2013
DIN EN ISO 9001:2015
DIN ISO/IEC 2-1:2011

ISAE 3402 Typ II Assessed

EWERK-Blog<https://blog.ewerk.com/> | 
LinkedIn<https://www.linkedin.com/company/ewerk-group> | 
Xing<https://www.xing.com/company/ewerk> | 
Twitter<https://twitter.com/EWERK_Group> | 
Facebook<https://de-de.facebook.com/EWERK.IT/>


Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.

Disclaimer Privacy:
Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist 
vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der 
bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, 
Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte 
informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die 
E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen 
Dank.

The contents of this e-mail (including any attachments) are confidential and 
may be legally privileged. If you are not the intended recipient of this 
e-mail, any disclosure, copying, distribution or use of its contents is 
strictly prohibited, and you should please notify the sender immediately and 
then delete it (including any attachments) from your system. Thank you.

Gesendet: Tuesday, October 13, 2020 9:53:16 PM
An: dev@cloudstack.apache.org 
Betreff: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support

Service account best suits the need. We can probably apply some RBAC on the 
account if possible

Sent from my iPhone


david.jum...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 

> On 12-Oct-2020, at 2:19 PM, David Jumani  wrote:
>
> Thanks Rakesh.
> Do you think it would be better to have the user provide the API keys or 
> create a service account and use its keys?
>
> 
> From: Rakesh v 
> http://www.rakeshv@gmail.com<http://www.rakeshv@gmail.com<http://www.rakeshv@gmail.com>>>
> Sent: Monday, October 12, 2020 5:12 PM
> To: dev@cloudstack.apache.org 
> Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
>
> I prefer providing an API to customers with necessary parameters rather than 
> providing yaml files to them. Using API we can do automation also and editing 
> yaml files can be sometimes messy
>
> Sent from my iPhone
>
>
> david.jum...@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
> @shapeblue
>
>
>
>> On 12-Oct-2020, at 1:13 PM, David Jumani  wrote:
>>
>> Hi Daan,
>>
>> Thanks for your feedback!
>> Wrt the ideas, Submitting a yaml to an API would be redundant since the user 
>> can deploy it himself.
>> The API proposal was to simplify it for the user so they can just pass min / 
>> max size as well as API keys if needed (so no tweaking a yaml file)
>> The scaleAPI could have a flag to indicate whether it enables autoscaling or 
>> not, and if enabled, the additional fields provided.
>>
>> Thanks,
>> David
>> 
>> From: Daan Hoogland 
>> Sent: Monday, October 12, 2020 4:36 PM
>> To: dev 
>> Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
>>
>> David,
>> as a general principle an API called scale should not be used to
>> configure autoscaling of  in my opinion.
>> So option 1 seems the best to me (an submitYamlForKubernetes-API?) However
>> instead of requiring an yaml we could just ask for th

Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support

[David Jumani]

Thanks Daan. Users within the same account can alter the cluster, so I'm 
thinking of a service user within the same account and use the service user's 
keys. This will also prevent any mess up if the user provides his keys and then 
later regenerates them.

From: Daan Hoogland 
Sent: Tuesday, October 13, 2020 3:28 PM
To: dev 
Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support

That is a good question. Is the user going to be the only user responsible
for messing up the k8 cluster, or will other users be able to as well? For
convenience and if audit is to not lay false balme on a user, I'd say
create a system/service account, if several users can mess up each other
with it... makes sense?

On Tue, Oct 13, 2020 at 11:10 AM David Jumani 
wrote:

> Sounds good. And do you think it would be better to have the user provide
> the API keys or create a service account and use its keys?
> 
> From: Daan Hoogland 
> Sent: Monday, October 12, 2020 6:28 PM
> To: dev 
> Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
>
> Davis, how about a separate API called setAutoScalingParameter or
> setAutoScalingLimits?
>
> On Mon, Oct 12, 2020 at 2:19 PM David Jumani 
> wrote:
>
> > Thanks Rakesh.
> > Do you think it would be better to have the user provide the API keys or
> > create a service account and use its keys?
> >
> > 
> > From: Rakesh v <www.rakeshv@gmail.com<
> http://www.rakeshv@gmail.com>>
> > Sent: Monday, October 12, 2020 5:12 PM
> > To: dev@cloudstack.apache.org 
> > Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
> >
> > I prefer providing an API to customers with necessary parameters rather
> > than providing yaml files to them. Using API we can do automation also
> and
> > editing yaml files can be sometimes messy
> >
> > Sent from my iPhone
> >
> >
> > david.jum...@shapeblue.com
> > www.shapeblue.com<http://www.shapeblue.com>
> > 3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
> > @shapeblue
> >
> >
> >
> > > On 12-Oct-2020, at 1:13 PM, David Jumani 
> > wrote:
> > >
> > > Hi Daan,
> > >
> > > Thanks for your feedback!
> > > Wrt the ideas, Submitting a yaml to an API would be redundant since the
> > user can deploy it himself.
> > > The API proposal was to simplify it for the user so they can just pass
> > min / max size as well as API keys if needed (so no tweaking a yaml file)
> > > The scaleAPI could have a flag to indicate whether it enables
> > autoscaling or not, and if enabled, the additional fields provided.
> > >
> > > Thanks,
> > > David
> > > 
> > > From: Daan Hoogland 
> > > Sent: Monday, October 12, 2020 4:36 PM
> > > To: dev 
> > > Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler
> support
> > >
> > > David,
> > > as a general principle an API called scale should not be
> used
> > to
> > > configure autoscaling of  in my opinion.
> > > So option 1 seems the best to me (an submitYamlForKubernetes-API?)
> > However
> > > instead of requiring an yaml we could just ask for the required fields
> > >
> > >> On Mon, Oct 12, 2020 at 12:51 PM David Jumani <
> > david.jum...@shapeblue.com>
> > >> wrote:
> > >>
> > >> Hi,
> > >>
> > >> I'm currently working on adding support for CloudStack as a cloud
> > provider
> > >> for Kubernetes to allow it to dynamically scale the cluster size based
> > on
> > >> capacity requirements.
> > >> It runs as a separate pod in its own deployment and requires an API
> and
> > >> Secret key to communicate with CloudStack.
> > >>
> > >> While that's going on, I'd like some feedback on how it can be
> > integrated
> > >> and even deployed from the CloudStack side. I have three proposals and
> > >> would like your input :
> > >>
> > >>  1.  Provide the deployment yaml file to the user, have them change
> the
> > >> min and max cluster size to suit their requirement, provide the API
> > keys as
> > >> Kubernetes secrets and deploy it themselves. (Most flexible as the
> user
> > can
> > >> change several autoscaling parameters as well)
> > >>  2.  Deploy it via the scaleKubernetesCluster API. This 

Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support

[David Jumani]

Sounds good. And do you think it would be better to have the user provide the 
API keys or create a service account and use its keys?

From: Daan Hoogland 
Sent: Monday, October 12, 2020 6:28 PM
To: dev 
Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support

Davis, how about a separate API called setAutoScalingParameter or
setAutoScalingLimits?

On Mon, Oct 12, 2020 at 2:19 PM David Jumani 
wrote:

> Thanks Rakesh.
> Do you think it would be better to have the user provide the API keys or
> create a service account and use its keys?
>
> 
> From: Rakesh v http://www.rakeshv@gmail.com>>
> Sent: Monday, October 12, 2020 5:12 PM
> To: dev@cloudstack.apache.org 
> Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
>
> I prefer providing an API to customers with necessary parameters rather
> than providing yaml files to them. Using API we can do automation also and
> editing yaml files can be sometimes messy
>
> Sent from my iPhone
>
>
> david.jum...@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
> @shapeblue
>
>
>
> > On 12-Oct-2020, at 1:13 PM, David Jumani 
> wrote:
> >
> > Hi Daan,
> >
> > Thanks for your feedback!
> > Wrt the ideas, Submitting a yaml to an API would be redundant since the
> user can deploy it himself.
> > The API proposal was to simplify it for the user so they can just pass
> min / max size as well as API keys if needed (so no tweaking a yaml file)
> > The scaleAPI could have a flag to indicate whether it enables
> autoscaling or not, and if enabled, the additional fields provided.
> >
> > Thanks,
> > David
> > 
> > From: Daan Hoogland 
> > Sent: Monday, October 12, 2020 4:36 PM
> > To: dev 
> > Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
> >
> > David,
> > as a general principle an API called scale should not be used
> to
> > configure autoscaling of  in my opinion.
> > So option 1 seems the best to me (an submitYamlForKubernetes-API?)
> However
> > instead of requiring an yaml we could just ask for the required fields
> >
> >> On Mon, Oct 12, 2020 at 12:51 PM David Jumani <
> david.jum...@shapeblue.com>
> >> wrote:
> >>
> >> Hi,
> >>
> >> I'm currently working on adding support for CloudStack as a cloud
> provider
> >> for Kubernetes to allow it to dynamically scale the cluster size based
> on
> >> capacity requirements.
> >> It runs as a separate pod in its own deployment and requires an API and
> >> Secret key to communicate with CloudStack.
> >>
> >> While that's going on, I'd like some feedback on how it can be
> integrated
> >> and even deployed from the CloudStack side. I have three proposals and
> >> would like your input :
> >>
> >>  1.  Provide the deployment yaml file to the user, have them change the
> >> min and max cluster size to suit their requirement, provide the API
> keys as
> >> Kubernetes secrets and deploy it themselves. (Most flexible as the user
> can
> >> change several autoscaling parameters as well)
> >>  2.  Deploy it via the scaleKubernetesCluster API. This will require
> >> adding additional parameters to the API such as minsize, maxsize, apikey
> >> and secretkey for the service to communicate with CloudStack. (Uses
> default
> >> autoscaling parameters, api keys provided by the user)
> >>  3.  Deploy it via the scaleKubernetesCluster API, but also create a
> >> service account and use its API keys to communicate with CloudStack. The
> >> user will still need to provide the minsize and maxsize to the API.
> (Uses
> >> default autoscaling parameters, api keys generated and used by a service
> >> account, which if deleted could cause issues)
> >>
> >> The design document can be found here :
> >>
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cluster+Autoscaler+for+CloudStack+Kubernetes+Service
> >>
> >> Additional info can be found here :
> >>
> >>
> https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md
> >>
> >> Look forward to hearing from you!
> >>
> >> Thanks,
> >> David
> >>
> >> david.jum...@shapeblue.com
> >> www.shapeblue.com<http://www.shapeblue.com>
> >> 3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
> >> @shapeblue
> >>
> >>
> >>
> >>
> >
> > --
> > Daan
> >
> > david.jum...@shapeblue.com
> > www.shapeblue.com<http://www.shapeblue.com>
> > 3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
> > @shapeblue
> >
> >
> >
>


--
Daan

david.jum...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 

Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support

[David Jumani]

Thanks Rakesh.
Do you think it would be better to have the user provide the API keys or create 
a service account and use its keys?


From: Rakesh v 
Sent: Monday, October 12, 2020 5:12 PM
To: dev@cloudstack.apache.org 
Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support

I prefer providing an API to customers with necessary parameters rather than 
providing yaml files to them. Using API we can do automation also and editing 
yaml files can be sometimes messy

Sent from my iPhone


david.jum...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 

> On 12-Oct-2020, at 1:13 PM, David Jumani  wrote:
>
> Hi Daan,
>
> Thanks for your feedback!
> Wrt the ideas, Submitting a yaml to an API would be redundant since the user 
> can deploy it himself.
> The API proposal was to simplify it for the user so they can just pass min / 
> max size as well as API keys if needed (so no tweaking a yaml file)
> The scaleAPI could have a flag to indicate whether it enables autoscaling or 
> not, and if enabled, the additional fields provided.
>
> Thanks,
> David
> 
> From: Daan Hoogland 
> Sent: Monday, October 12, 2020 4:36 PM
> To: dev 
> Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
>
> David,
> as a general principle an API called scale should not be used to
> configure autoscaling of  in my opinion.
> So option 1 seems the best to me (an submitYamlForKubernetes-API?) However
> instead of requiring an yaml we could just ask for the required fields
>
>> On Mon, Oct 12, 2020 at 12:51 PM David Jumani 
>> wrote:
>>
>> Hi,
>>
>> I'm currently working on adding support for CloudStack as a cloud provider
>> for Kubernetes to allow it to dynamically scale the cluster size based on
>> capacity requirements.
>> It runs as a separate pod in its own deployment and requires an API and
>> Secret key to communicate with CloudStack.
>>
>> While that's going on, I'd like some feedback on how it can be integrated
>> and even deployed from the CloudStack side. I have three proposals and
>> would like your input :
>>
>>  1.  Provide the deployment yaml file to the user, have them change the
>> min and max cluster size to suit their requirement, provide the API keys as
>> Kubernetes secrets and deploy it themselves. (Most flexible as the user can
>> change several autoscaling parameters as well)
>>  2.  Deploy it via the scaleKubernetesCluster API. This will require
>> adding additional parameters to the API such as minsize, maxsize, apikey
>> and secretkey for the service to communicate with CloudStack. (Uses default
>> autoscaling parameters, api keys provided by the user)
>>  3.  Deploy it via the scaleKubernetesCluster API, but also create a
>> service account and use its API keys to communicate with CloudStack. The
>> user will still need to provide the minsize and maxsize to the API. (Uses
>> default autoscaling parameters, api keys generated and used by a service
>> account, which if deleted could cause issues)
>>
>> The design document can be found here :
>>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cluster+Autoscaler+for+CloudStack+Kubernetes+Service
>>
>> Additional info can be found here :
>>
>> https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md
>>
>> Look forward to hearing from you!
>>
>> Thanks,
>> David
>>
>> david.jum...@shapeblue.com
>> www.shapeblue.com<http://www.shapeblue.com>
>> 3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
>> @shapeblue
>>
>>
>>
>>
>
> --
> Daan
>
> david.jum...@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
> @shapeblue
>
>
>

Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support

[David Jumani]

Hi Daan,

Thanks for your feedback!
Wrt the ideas, Submitting a yaml to an API would be redundant since the user 
can deploy it himself.
The API proposal was to simplify it for the user so they can just pass min / 
max size as well as API keys if needed (so no tweaking a yaml file)
The scaleAPI could have a flag to indicate whether it enables autoscaling or 
not, and if enabled, the additional fields provided.

Thanks,
David

From: Daan Hoogland 
Sent: Monday, October 12, 2020 4:36 PM
To: dev 
Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support

David,
as a general principle an API called scale should not be used to
configure autoscaling of  in my opinion.
 So option 1 seems the best to me (an submitYamlForKubernetes-API?) However
instead of requiring an yaml we could just ask for the required fields

On Mon, Oct 12, 2020 at 12:51 PM David Jumani 
wrote:

> Hi,
>
> I'm currently working on adding support for CloudStack as a cloud provider
> for Kubernetes to allow it to dynamically scale the cluster size based on
> capacity requirements.
> It runs as a separate pod in its own deployment and requires an API and
> Secret key to communicate with CloudStack.
>
> While that's going on, I'd like some feedback on how it can be integrated
> and even deployed from the CloudStack side. I have three proposals and
> would like your input :
>
>   1.  Provide the deployment yaml file to the user, have them change the
> min and max cluster size to suit their requirement, provide the API keys as
> Kubernetes secrets and deploy it themselves. (Most flexible as the user can
> change several autoscaling parameters as well)
>   2.  Deploy it via the scaleKubernetesCluster API. This will require
> adding additional parameters to the API such as minsize, maxsize, apikey
> and secretkey for the service to communicate with CloudStack. (Uses default
> autoscaling parameters, api keys provided by the user)
>   3.  Deploy it via the scaleKubernetesCluster API, but also create a
> service account and use its API keys to communicate with CloudStack. The
> user will still need to provide the minsize and maxsize to the API. (Uses
> default autoscaling parameters, api keys generated and used by a service
> account, which if deleted could cause issues)
>
> The design document can be found here :
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cluster+Autoscaler+for+CloudStack+Kubernetes+Service
>
> Additional info can be found here :
>
> https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md
>
> Look forward to hearing from you!
>
> Thanks,
> David
>
> david.jum...@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
> @shapeblue
>
>
>
>

--
Daan

david.jum...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 

[DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support

[David Jumani]

Hi,

I'm currently working on adding support for CloudStack as a cloud provider for 
Kubernetes to allow it to dynamically scale the cluster size based on capacity 
requirements.
It runs as a separate pod in its own deployment and requires an API and Secret 
key to communicate with CloudStack.

While that's going on, I'd like some feedback on how it can be integrated and 
even deployed from the CloudStack side. I have three proposals and would like 
your input :

  1.  Provide the deployment yaml file to the user, have them change the min 
and max cluster size to suit their requirement, provide the API keys as 
Kubernetes secrets and deploy it themselves. (Most flexible as the user can 
change several autoscaling parameters as well)
  2.  Deploy it via the scaleKubernetesCluster API. This will require adding 
additional parameters to the API such as minsize, maxsize, apikey and secretkey 
for the service to communicate with CloudStack. (Uses default autoscaling 
parameters, api keys provided by the user)
  3.  Deploy it via the scaleKubernetesCluster API, but also create a service 
account and use its API keys to communicate with CloudStack. The user will 
still need to provide the minsize and maxsize to the API. (Uses default 
autoscaling parameters, api keys generated and used by a service account, which 
if deleted could cause issues)

The design document can be found here :
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cluster+Autoscaler+for+CloudStack+Kubernetes+Service

Additional info can be found here :
https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md

Look forward to hearing from you!

Thanks,
David

david.jum...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 

Triage Permission

[David Jumani]

Hi,

While working with the CloudStack repository, logging issues and contributing, 
I've noticed a long turnaround time for issues and pull requests. I guess that 
it might have to do with the fact that only committers can modify and manage 
them.
To alleviate this, I'd like to propose the granting the Triage 
permission
 on GitHub to some of the active members of our community.


They can manage issues / pull requests, and add bots to automate mundane tasks, 
without having write access to the repository.
This would be a great stepping stone for growing the community, reducing the 
workload on Committers and would help in keeping community members and 
developers engaged in the project!

As a trial, I'd propose the following users be granted it and based on the 
result / feedback we can continue to add more members
@shwstppr @davidjumani @Pearl1594 @ACSGitBot @Spaceman1984 @sureshanaparti 
@vladimirpetrov

Thanks,
David


david.jum...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 

Re: Question about documentation

[David Jumani]

Hi Slavka,

You can have a look at the documentation here and add the docs of your feature 
(where you think it's appropriate)
http://docs.cloudstack.apache.org/en/latest/adminguide/storage.html?highlight=snapshot#working-with-volume-snapshots

You can edit the docs and send a PR
https://github.com/apache/cloudstack-documentation/

Thanks,
David

From: Slavka Peleva 
Sent: Monday, September 14, 2020 6:12 PM
To: dev@cloudstack.apache.org 
Subject: Question about documentation

Hi all,

We have a pull request #3724
  for which Andrija Panic
 requested documentation. I couldn't
find any guide or requirements on how to structure documents with new
features. Could you please help with this -  where are we supposed to
submit changes, and are there any requirements of the structure?

Thanks in advance!

Best regards,
Slavka P.

david.jum...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 

Re: Get console URL

[David Jumani]

Hi Nino,

Right now there is no API to generate the URL. You'll have to craft an http 
request
http://://client/console?cmd=access=

Then scrape the response for the console proxy url along with the token within 
a frame like you see in the logs and use it

Thanks,
David

From: El Nino 
Sent: Monday, August 3, 2020 6:14 PM
To: dev@cloudstack.apache.org 
Subject: Get console URL

Hi,

Could you help me please.

I need to get the console url for instance to integrate it to my application.

On the cloudstack-management server I have log bellow.

the console url is :: r-411-KDhttp://XXX.XXX.XXX.XXX/resource/noVNC/vnc_lite.html?port=8080=WZEwCaI3M0ccgQnMpeRW6acWcJLgO-g1xYraGkrcvEztvW_zTZeVUx84aMldw0i2z4fc-nhKOK-sS1h4tSPcNKFvxnpSTQuczTyIWxT6XjaArg7GotG0pyiMq1c0LI2SVkwDoF--QP1h1yF26TssL2Hfm0cemHg_ezxv_UTV0Um0mekl4RZlZFyn6Yv7ZO7y9uFu1Gk4pP7mCgOlFgNipVABjL7C9NEB6D7bpOrvTM6H2kogm5vzf5R2-BIy1wdJTqJ6ZrHRqCwR8qc8SKFgiw;>


No api command to get this url. so maybe we have another way to do this ?

I’am using the last 4.15 SNAPSHOT version.

Thank You.

david.jum...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 

Intro

[David Jumani]

Hi Guys,

David here. I've recently joined Shapeblue and am exited to join the community. 
Looking forward to working with you all as well as  learning and contributing 
to the community.

Thanks,
David Jumani
david.jum...@shapeblue.com

david.jum...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue