RE: [VOTE] next version 20 instead of 4.20

[Paul Angus]

That logic doesn't hold with what's proposed

Taking your interpretation, after moving to 20.x.y we would then have to stay 
on 20.x.y until "incompatible API changes" happen. New features and updates 
would go into 20 . x+1 . y  which only achieves removing the security fix dot 
releases nomenclature.


MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backward compatible manner
PATCH version when you make backward compatible bug fixes



-Original Message-
From: Daan Hoogland  
Sent: Wednesday, March 6, 2024 8:57 AM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] next version 20 instead of 4.20

I think we will (and have) changed APIs and dropped plugin support in major 
versions with at least a deprecation period. this is exactly the reason I now 
(finally) proposed we should drop the 4 and proceed with regarding the second 
number as the primary version. Semantic versioning is well defined as a three 
number scheme that we follow otherwise.
this is also how https://semver.org/ defines it. Our only difference with that 
is that we do not allow backwards compatible feature added in major versions, 
which we could decide to do or don't independent of whether we drop the 4 or 
not.

I agree that we could codify our protocol first.

On Wed, Mar 6, 2024 at 5:54 AM Rohit Yadav  wrote:
>
> Daniel, Daan, others,
>
> Could you explain why you’d break CloudStack’s rest-like APIs? Isn’t the 
> intention of dropping the 4. as we may never see a 5.x that involves major 
> changes involving API incompatibility?
>
> Regards.
>
>
>
> 
> From: Guto Veronezi 
> Sent: Wednesday, March 6, 2024 4:00:30 AM
> To: dev@cloudstack.apache.org 
> Subject: Re: [VOTE] next version 20 instead of 4.20
>
> > By agreeing to drop the "4" I think we're effectively voting and agreeing 
> > that we'll not be breaking APIs.
> That is not what was discussed in the thread [1]. If we agree that we 
> will not break APIs, I am -1 on dropping the "4". We need to create a 
> protocol along with the proposal, otherwise, we will be subjective 
> about the topic and will be agreeing on something for different reasons.
>
> [1] https://lists.apache.org/thread/yxxjzov5dqrfsogth6kcq2r0wn8rzljv
>
> On 3/5/24 15:10, Paul Angus wrote:
> > Hi Rohit, thank you
> >
> > So to recap;
> >
> > Semantic versioning goes (in our use):
> >  .  . 
> >  . 
> >
> > And as I understand it you're looking to go
> >
> >  .  .  Starting 
> > from 20
> >
> > I'd ask the question - are there any big/disruptive changes people 
> > would want to bundle together to keep the semantic versioning and 
> > move to 5.x.y.z
> >
> > I'm assuming not, so the move proposed is to drop semantic versioning and 
> > continue from 20, understanding that we would lose the mechanism to warn of 
> > very disruptive changes (for what it's worth).
> >
> > I've no objection to it.  The issue was, that reading the thread, people 
> > had different takes on what the change was, what would it do and what it 
> > meant. And also incorrect understandings of semantic versioning.
> >
> > So, to be pedantic, and have a clearly defined vote, I'd change the 
> > vote to something like "Drop semantic versioning and continue from 
> > 20".  And include your explanation about moving to 
> >  .  . 
> >
> > I would be ok to +1 that ^^^
> >
> > -paul
> >
> > -Original Message-
> > From: Rohit Yadav 
> > Sent: Tuesday, March 5, 2024 4:02 PM
> > To: dev@cloudstack.apache.org; us...@cloudstack.apache.org
> > Subject: Re: [VOTE] next version 20 instead of 4.20
> >
> > As I understand Daan's vote proposal and from the previous discussion 
> > thread, the current scheme that results in a release like 4.20.x.y would 
> > simply become 20.a.b, wherein "a" is for maintenance release (counter, 
> > starting with 0) and "b" is only used for security releases (counter, 
> > starting with 0).
> >
> > The voting thread is about "deciding to drop the 4 from our versioning 
> > scheme", wherein the next CloudStack version would become "20" instead of 
> > "4.20". By agreeing to drop the "4" I think we're effectively voting and 
> > agreeing that we'll not be breaking APIs. Some other opensource projects 
> > have done something similar too. Of course, this needs to be properly 
> > explained and documented both by a blog article and on the project wiki.
> >
> > Paul - are you satisfied with the explanations and discussions, are 

RE: [VOTE] next version 20 instead of 4.20

[Paul Angus]

Hi Rohit, thank you

So to recap;

Semantic versioning goes (in our use):
 .  .  . 


And as I understand it you're looking to go

 .  . 
Starting from 20

I'd ask the question - are there any big/disruptive changes people would want 
to bundle together to keep the semantic versioning and move to 5.x.y.z

I'm assuming not, so the move proposed is to drop semantic versioning and 
continue from 20, understanding that we would lose the mechanism to warn of 
very disruptive changes (for what it's worth).

I've no objection to it.  The issue was, that reading the thread, people had 
different takes on what the change was, what would it do and what it meant. And 
also incorrect understandings of semantic versioning.

So, to be pedantic, and have a clearly defined vote, I'd change the vote to 
something like "Drop semantic versioning and continue from 20".  And include 
your explanation about moving to
 .  . 

I would be ok to +1 that ^^^

-paul 

-Original Message-
From: Rohit Yadav  
Sent: Tuesday, March 5, 2024 4:02 PM
To: dev@cloudstack.apache.org; us...@cloudstack.apache.org
Subject: Re: [VOTE] next version 20 instead of 4.20

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

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

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


Regards.

 



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

Hi Daan,


>From our wiki page:

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

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


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


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

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

- Paul

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

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

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

On Tue, Feb 20, 2024 at 5:06 AM Vivek Kumar  
wrote:
>
> Why not 5.0 ? Then it will be like 5.1, 5.2 in the future.  Just asking ..!
>
>
> > On 19-Feb-2024, at 10:49 PM, Paul Angus  wrote:
> >
> > Hi Daan,
> >

RE: [VOTE] next version 20 instead of 4.20

[Paul Angus]

Hi Daan,


>From our wiki page:

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

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


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


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

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

- Paul

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

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

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

On Tue, Feb 20, 2024 at 5:06 AM Vivek Kumar  
wrote:
>
> Why not 5.0 ? Then it will be like 5.1, 5.2 in the future.  Just asking ..!
>
>
> > On 19-Feb-2024, at 10:49 PM, Paul Angus  wrote:
> >
> > Hi Daan,
> >
> > Can you clarify what we are actually voting on please.
> >
> > In thread that is linked I've seen:
> >
> > "[the vote] will be to adjust to the semantic versioning system."
> > - you can't go to 20 AND keep semantic versioning. The act of going to 20 
> > breaks semantic versioning [1].
> >
> > " drop the 4 at version 20 and continue as usual with minor and patch level 
> > updates as we have in the past."
> > - what's supposed to come next ? in lieu of what would have been 4.21 will 
> > it be 21 ?  is it going to be 20.1 then 20.2 ?
> >
> > From the thread and how people are referring to 'minor versions', there is 
> > a misunderstanding as to what semantic versioning means. For our project 
> > its explained here [1].   Major versions meaning "probably going to break a 
> > load of people's stuff', with minor versions not breaking stuff (at least 
> > not on purpose). So I get calling them minor versions really underplays the 
> > changes it can hold.
> >
> >
> > I'm going to stick in a -1.  Not as hard 'no' to any changes, but I think 
> > the vote should be on 'A change to the version numbering scheme' and then 
> > what is proposed properly laid out.
> >
> >
> >
> >
> > [1]   https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases 
> > (section on versioning about 2/3 down)
> >
> > -Original Message-
> > From: Daan Hoogland 
> > Sent: Monday, February 19, 2024 12:50 PM
> > To: dev 
> > Cc: users 
> > Subject: [VOTE] next version 20 instead of 4.20
> >
> > LS,
> >
> > This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be 
> > counted please reply to dev@.
> >
> > As discussed in [1] we are deciding to drop the 4 from our versioning 
> > scheme. The result would be that the next major version will be 20 instead 
> > of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the 
> > versions are processed numerically there are no technical impediments.
> >
> > +1 agree (next major version as 20
> > 0 (no opinion)
> > -1 disagree (k

RE: [VOTE] next version 20 instead of 4.20

[Paul Angus]

Hi Daan,

Can you clarify what we are actually voting on please.

In thread that is linked I've seen:

"[the vote] will be to adjust to the semantic versioning system."
- you can't go to 20 AND keep semantic versioning. The act of going to 20 
breaks semantic versioning [1].

" drop the 4 at version 20 and continue as usual with minor and patch level 
updates as we have in the past."
- what's supposed to come next ? in lieu of what would have been 4.21 will it 
be 21 ?  is it going to be 20.1 then 20.2 ?

>From the thread and how people are referring to 'minor versions', there is a 
>misunderstanding as to what semantic versioning means. For our project its 
>explained here [1].   Major versions meaning "probably going to break a load 
>of people's stuff', with minor versions not breaking stuff (at least not on 
>purpose). So I get calling them minor versions really underplays the changes 
>it can hold.


I'm going to stick in a -1.  Not as hard 'no' to any changes, but I think the 
vote should be on 'A change to the version numbering scheme' and then what is 
proposed properly laid out.  




[1]   https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases (section 
on versioning about 2/3 down)

-Original Message-
From: Daan Hoogland  
Sent: Monday, February 19, 2024 12:50 PM
To: dev 
Cc: users 
Subject: [VOTE] next version 20 instead of 4.20

LS,

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

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

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

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

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

--
Daan

IMPORTANT FROM ASF LEGAL - Use of Generative AI tools

[Paul Angus]

Hi All,

 

This has been shared by the ASF's Legal Committee regarding the use of AI in
Apache projects.  If you are or plan to use AI tools to help with your
commits (code or otherwise) please take the time to read it.

 

https://www.apache.org/legal/generative-tooling.html

 

 

 

Kind regards

 

Paul Angus

 

Daan Hoogland - New ASF Member

[Paul Angus]

 

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: tungsten libraries

[Paul Angus]

Might be worth a comment in the commit pointing to the origin on the fork and 
the Apache license contained in it.  But I'd agree with Rohit.

Also - Can we remember not to cross-post private and public :thankyou:

Paul

-Original Message-
From: Rohit Yadav 
Sent: Tuesday, January 24, 2023 10:30 AM
To: priv...@cloudstack.apache.org
Cc: dev 
Subject: Re: tungsten libraries

I don't know if this violates any rules, as far as I both the fork repo is 
under valid apache license.

The standard process is to publish the jar in a public maven repo. Can this be 
done and we refer to the dependency like other dependencies?

Regards.

On Mon, 23 Jan 2023 at 13:43, Daan Hoogland  wrote:

> LS,
>
> TL;DR we are about to merge a reference to a dependency in a (privare)
> fork of an apl2 licensed project.
> We are planning to merge the (backend-) plugin for tungsten in the
> coming days. If regression tests show no big failures of course. There
> is one issue I want devs and PMCs opinions on. Please see our esteemed
> comment on the subject [1].
> Do we find including a dependency this way acceptable? I personally
> have no problem with it but want to make sure I am not violating any
> laws, by-laws or feelings with merging it like this.
> We are still doing regression tests in advanced zon with security
> groups for this, and lazy consensus applies.
> Please be heard if you see a reason not to do this.
>
> [1]
> https://github.com/apache/cloudstack/pull/7065#issuecomment-1398857494
>
> thanks,
>
>
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] Github Discussions for CloudStack?

[Paul Angus]

Thank you for confirming what I said about the ASFs requirements around mailing 
lists.

However, having primary and secondary places to look for threads could make it 
harder for users to find answers to questions that have been asked before; so 
I'm asking that this issue be considered fully so that we can ensure that we 
support users as best we can.


Kind Regards


Paul Angus

-Original Message-
From: Rohit Yadav  
Sent: Monday, December 19, 2022 4:16 PM
To: dev@cloudstack.apache.org; us...@cloudstack.apache.org
Subject: Re: [DISCUSS] Github Discussions for CloudStack?

Update, tl;dr - ASF infra has allowed the use of Github Discussions only for 
user queries and not development and this is because they don't have two-way 
mirroring of the same enabled on mailing lists (yet). This is also not 
enabled/controlled via asf yaml yet and must be requested once project consesus 
is reached 
(https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-GitHubDiscussions).

My understanding (based on interactions with ASF infra) is that mailing lists 
are recognised medium to be used by ASF projects for development [1], and users 
mailing lists exist for users as primary support channels but not mandatory. 
This is also why ASF infra is allowing Github Discussions for only user queries 
- they wouldn't enable something for a project that isn't ASF compliant.

I think it could be a good idea to try Github Discussions as means of providing 
support, one specific thing I like about Github Discussions is the 
classification of user queries as Q, for example:
https://github.com/apache/airflow/discussions/categories/q-a
https://github.com/apache/superset/discussions/categories/q-a-help

[1] https://www.apache.org/foundation/mailinglists.html


Regards.


From: Paul Angus 
Sent: Sunday, December 18, 2022 18:45
To: dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org 
Subject: RE: [DISCUSS] Github Discussions for CloudStack?

If this makes discussions more accessible, it could be a good thing.

However, as mentioned by Daniel and Nux, unless there is a two-way mirror of 
discussions on mailing lists and Github discussions, it's going to split 
everyone's attention, or double where anyone has to look for answers.

Mailing lists are the only medium recognised by the ASF, so any 'official' 
conversations must be had on, or replicated to, the mailing lists. The stats 
gathered by the ASF are also based on mailing list activity.

I think these guardrails need to be in place first before trying.

Alternatively, if the issue is simply that questions are popping up in Github 
that shouldn't really be there.  Then it would be much simpler to educate 
people and just point them to the mailing list whenever it happens.

Paul.

 


-Original Message-
From: David Jumani 
Sent: Thursday, December 15, 2022 3:21 AM
To: dev@cloudstack.apache.org; us...@cloudstack.apache.org
Subject: Re: [DISCUSS] Github Discussions for CloudStack?

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: [DISCUSS] Github Discussions for CloudStack?

[Paul Angus]

If this makes discussions more accessible, it could be a good thing.

However, as mentioned by Daniel and Nux, unless there is a two-way mirror of 
discussions on mailing lists and Github discussions, it's going to split 
everyone's attention, or double where anyone has to look for answers.

Mailing lists are the only medium recognised by the ASF, so any 'official' 
conversations must be had on, or replicated to, the mailing lists. The stats 
gathered by the ASF are also based on mailing list activity.

I think these guardrails need to be in place first before trying.

Alternatively, if the issue is simply that questions are popping up in Github 
that shouldn't really be there.  Then it would be much simpler to educate 
people and just point them to the mailing list whenever it happens.

Paul.

-Original Message-
From: David Jumani  
Sent: Thursday, December 15, 2022 3:21 AM
To: dev@cloudstack.apache.org; us...@cloudstack.apache.org
Subject: Re: [DISCUSS] Github Discussions for CloudStack?

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: Introducing Bart and Ruben

[Paul Angus]

A big welcome!

-Original Message-
From: Nux  
Sent: Tuesday, August 9, 2022 10:23 AM
To: dev@cloudstack.apache.org
Cc: ruben.bo...@cldin.eu; bart.mey...@cldin.eu; Wido den Hollander 

Subject: Re: Introducing Bart and Ruben

Welcome aboard, guys!

---
Nux
www.nux.ro

On 2022-08-08 13:43, Wido den Hollander wrote:
> Hi devs,
> 
> Recently Bart and Ruben (CC) joined CLDIN (was PCextreme) as DevOps 
> engineers and will be working on CloudStack and start to contribute to 
> the project.
> 
> In the coming months they'll finding their way around in the community 
> and code and you should start seeing Pull Requests from them coming 
> in.
> 
> We'll try to make the CCC in Bulgaria later this year!
> 
> Wido

RE: [ANNOUNCE] Apache CloudStack 4.17.0.0 Release

[Paul Angus]

Well done!

-Original Message-
From: Rohit Yadav  
Sent: Wednesday, June 8, 2022 9:33 AM
To: dev@cloudstack.apache.org
Subject: Re: [ANNOUNCE] Apache CloudStack 4.17.0.0 Release

Thanks Nicolas and the 4.17 release team 拾 and congratulations everyone for 
the new release.

Regards.

Regards.

From: Daman Arora 
Sent: Tuesday, June 7, 2022 9:48:14 PM
To: dev@cloudstack.apache.org 
Subject: Re: [ANNOUNCE] Apache CloudStack 4.17.0.0 Release

Way to go!!

On Tue, Jun 7, 2022, 12:12 PM Ian Rae  wrote:

> 
>
>
> On Tue, Jun 7, 2022 at 12:04 PM Pritam Neog 
> wrote:
>
> > Congrats to everyone involved and thank you Nicolas 
> >
> > On Tue, Jun 7, 2022 at 8:39 PM Nicolas Vazquez 
> > wrote:
> >
> > > *The Apache Software Foundation Announces Apache**®** 
> > > CloudStack**®**
> > > v4.17*
> > >
> > > Apache CloudStack 4.17.0.0 is a 4.17 LTS release with 383 new 
> > > features, improvements and bug fixes since 4.16, including 16 
> > > major new features. Some of the highlights include:
> > >
> > > - IPv6 with Static Routing
> > > - Zero Downtime Upgrades
> > > - Virtual Router Live Patching
> > > - CloudStack Status & management
> > > - User Shared Networks
> > > - StorPool storage plugin
> > > - Storage-based Snapshots for KVM Instances
> > > - Attach and detach features to UI for ROOT disks
> > > - Enable CloudStack to use multiple LOCAL storage pools
> > > - Multiple SSH Keys support
> > > - Reserve and release Public IPs
> > >
> > > # Documentation
> > > The full list of new features can be found in the project release 
> > > notes at
> > >
> http://docs.cloudstack.apache.org/en/4.17.0.0/releasenotes/changes.htm
> l
> > >
> > > The CloudStack documentation includes upgrade instructions from 
> > > previous versions of Apache CloudStack, and can be found at:
> > > http://docs.cloudstack.apache.org/en/4.17.0.0/upgrading/index.html
> > >
> > > The official installation, administration and API documentation 
> > > for each of the releases are available on our documentation page:
> > > http://docs.cloudstack.apache.org/
> > >
> > > # Downloads
> > > The official source code for the 4.17.0.0 release can be 
> > > downloaded from our downloads page: 
> > > http://cloudstack.apache.org/downloads.html
> > >
> > > In addition to the official source code release, individual 
> > > contributors have also made convenience binaries available on the 
> > > Apache CloudStack download page, and can be found at:
> > >
> > > https://download.cloudstack.org/ubuntu/dists/
> > > https://download.cloudstack.org/centos/7/
> > > https://download.cloudstack.org/centos/8/
> > > https://download.cloudstack.org/suse/15
> > > https://www.shapeblue.com/packages/
> > >
> >
> >
> > --
> > Pritam
> >
>

 

RE: Update Rules for Default Roles

[Paul Angus]

Hi Ranjit,

This is by design. You need to create a copy of the Domain Admin role and 
modify that.  You can then assign the new version to accounts/users.

This is because the 'default' role changes as new APIs are added or modified.  
Having your own version gives you a fixed set of rules.



-Original Message-
From: Ranjit Jadhav  
Sent: Friday, April 22, 2022 6:05 AM
To: us...@cloudstack.apache.org; dev 
Subject: Update Rules for Default Roles

Hello Folks,

I am getting the below error while trying to update Rules for Role Domain 
Admin, any suggestions on a workaround.

Request Failed (531)
Role permission cannot be added for Default roles

Any hint/solution will be of great help.

Thanks and regards,
Ranjit

RE: CloudStack Collaboration Conference 2022 - November 14-16

[Paul Angus]

Just throwing this out there - ApacheCon will be in New Orleans 3-6th
October.



Kind Regards


Paul Angus

-Original Message-
From: Nicolas Vazquez  
Sent: Tuesday, April 5, 2022 4:46 PM
To: us...@cloudstack.apache.org; dev@cloudstack.apache.org; Ivet Petrova

Subject: Re: CloudStack Collaboration Conference 2022 - November 14-16

Sounds great, thanks Ivet!

Regards,
Nicolas Vazquez


From: Wido den Hollander 
Date: Tuesday, 5 April 2022 at 12:26
To: us...@cloudstack.apache.org ,
dev@cloudstack.apache.org , Ivet Petrova

Subject: Re: CloudStack Collaboration Conference 2022 - November 14-16
Sounds good! I'll do my best to be present!

(And make sure there's a bar nearby! ;-) )

Wido

Op 05-04-2022 om 16:57 schreef Alex Mattioli:
> Sounds amazing @Ivet Petrova
>
>
>
>
>
> -Original Message-
> From: Daman Arora 
> Sent: 05 April 2022 16:51
> To: dev@cloudstack.apache.org
> Cc: users 
> Subject: Re: CloudStack Collaboration Conference 2022 - November 14-16
>
> Sounds like a good idea to me.
>
> Thanks,
> Daman Arora.
>
> On Tue., Apr. 5, 2022, 10:45 a.m. Ivet Petrova, 
> 
> wrote:
>
>> Hi all,
>>
>> I am working on the idea for the CloudStack Collaboration Conference
2022.
>> I was thinking that this time we can make it as a hybrid event and 
>> the end of the year - November 14-16th.
>> We will choose one physical location in Europe and will also stream 
>> the whole event online as previous year for the people who 
>> cannot/does not want to travel.
>> If nobody is against, I will start some organization plan.
>>
>> Kind regards,
>>
>>
>>
>>
>>

 

RE: [SHARE] CAPC - Kubernetes CAPI Provider for Apache CloudStack

[Paul Angus]

Great, well done!

Kind Regards


Paul Angus

-Original Message-
From: Nux  
Sent: Monday, March 7, 2022 1:10 PM
To: dev@cloudstack.apache.org
Cc: us...@cloudstack.apache.org
Subject: Re: [SHARE] CAPC - Kubernetes CAPI Provider for Apache CloudStack

Well done and thanks!

---
Nux!
www.nux.ro

On 2022-03-07 12:43, Rohit Yadav wrote:
> Hi all,
> 
> I thought everybody would like to know that my colleagues and I at 
> ShapeBlue have been recently working on a Kubernetes CAPI provider for 
> Apache CloudStack (CAPC,
> https://github.com/aws/cluster-api-provider-cloudstack) in a joint 
> collaboration with AWS (Amazon Web Services).
> 
> It is virtually finished and we’re in the process of donating the CAPC 
> provider [1] to CNCF licensed under Apache Public License v2. Further 
> development will be done under the Kubernetes Cluster Lifecycle SIG 
> community [2][3].
> 
> The Kubernetes Cluster API (https://cluster-api.sigs.k8s.io/)
> simplifies provisioning, upgrading, and operating multiple Kubernetes 
> clusters into specific target infrastructures using a consistent and 
> declarative way. A CAPI provider for Apache CloudStack makes 
> CloudStack one of those target infrastructures 
> (https://cluster-api.sigs.k8s.io/reference/providers.html).
> 
> The provider is ready for use and has gone through extensive testing 
> against CloudStack 4.14-4.16 across KVM, VMware, and XenServer/XCP-ng 
> hypervisors [6] and has passed the e2e as well as k8s conformance 
> tests.
> 
> After the donation of CAPC is complete, like other providers, we'll 
> work towards creating a proper docs website on how to participate, 
> collaborate, use and develop CAPC, work on installation and usage 
> guides and tutorial/training videos; for now, if anybody is interested 
> in a demo our David has created a 10-min video [4].
> 
> We would like to ask all of you for your support - testing the CAPC 
> provider and sending feedback – would also be interested in hearing if 
> people here will find this useful.
> 
> If anybody is interested in collaborating on the future development, 
> you may participate on the k8s sig-cluster-lifecycle mailing list 
> https://groups.google.com/g/kubernetes-sig-cluster-lifecycle and soon 
> you may join a new #cluster-api-cloudstack slack channel [5] under the 
> Kubernetes project slack (users/developers can get an invite via 
> http://slack.k8s.io, we've requested k8s project to create this new 
> slack channel which is pending approval [5]).
> 
> [1] https://github.com/aws/cluster-api-provider-cloudstack
> [2] https://github.com/kubernetes/org/issues/3279
> [3]
> https://groups.google.com/g/kubernetes-sig-cluster-lifecycle/c/sg46hga
> IzJs/m/KcAqxSt5AQAJ
> [4]
> https://shapeblue-engineering-videos.s3.eu-west-1.amazonaws.com/capc/c
> apc-demo-acs416.mp4 [5] 
> https://github.com/kubernetes/community/pull/6427
> [6] http://download.cloudstack.org/templates/capi-test/
> 
> 
> Regards.

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

[Paul Angus]

Yes,

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

Kind Regards


Paul Angus

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

Congratulations Simon!

Thank you Gabriel, for your work.

Regards,
Suresh

On Thu, Mar 17, 2022 at 4:27 PM Rohit Yadav  wrote:
>
> Congratulations Simon! And thank you Gabriel.
>
> Regards.
>
> On Thu, Mar 17, 2022 at 3:25 PM Gabriel Beims Bräscher 
>  wrote:
> >
> > Hello, all CloudStack community!
> >
> > It gives me great pleasure to announce that the ASF board last night 
> > accepted our PMC's nomination of Simon Weller as the next PMC Chair 
> > / VP of the Apache CloudStack project.
> >
> > I would like to thank everyone for the support I've received over the past 
> > year.
> > It was a great honor being the PMC Chair of this amazing project/community!
> >
> > To Simon, my sincere congratulations, and I wish you success in the new 
> > role!
> > Very well deserved!
> >
> > Please join me in congratulating Simon, the CloudStack PMC Chair / VP.
> >
> > Best Regards,
> > Gabriel Bräscher.

RE: How are you monitoring Cloudstack?

[Paul Angus]

Hi Nux,

At Ticketmaster we use the Prometheus exporter.  We about to work on adding
more detail to what's exported wrt to VMs, as it very infrastructure focused
out-of-the-box.



Kind regards

Paul Angus

-Original Message-
From: Nux  
Sent: 02 March 2022 10:56
To: us...@cloudstack.apache.org; dev@cloudstack.apache.org
Subject: Re: How are you monitoring Cloudstack?

Hi!

Another nudge on the $subject in case people missed this.

If you have a functioning way of monitoring Cloudstack & co in your
organisation I'd like to hear about it.
It doesn't have to be anything exotic, so don't be shy as long as we have
anything to talk about.

Thanks :)


On 2022-02-21 14:38, Nux! wrote:
> Hi folks,
> 
> If anyone cares to share (on or off list) with me a few words about 
> how they are monitoring Cloudstack and related infrastructure that'd 
> be lovely.
> I'm trying to find out what are the choices currently and how we can 
> improve the overall experience.
> 
> Don't be shy!
> 
> Cheers

RE: [VOTE] CentOS 7 KVM binaries

[Paul Angus]

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

There's no mention of removing support for anything.  If there is an intention 
removing support for existing components as part of this, then I agree 
completely with Rohit's  -1 on it.



Kind Regards


Paul Angus

-Original Message-
From: Wei ZHOU  
Sent: Wednesday, March 2, 2022 7:06 AM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] CentOS 7 KVM binaries

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

-Wei

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

> I had assumed this was a non-technical discussion/vote where the 
> changes are made in docs on suggested changes to how CloudStack is 
> deployed and used with CentOS7. I assumed this will follow as a doc PR to the 
> QIG.
>
> Changes to docs aren't normally considered technical as per our 
> project bylaws as they don't impact changes in source code or 
> releases. Three different PMCs have already advised on this thread 
> that voting isn't mandatory for this.
>
> However, assuming Daniel has followed the bylaws and is suggesting 
> this as a technical change that removes support in source code or 
> releases, then I oppose such a change.
>
> -1 (binding/veto) if we're going to technically remove support for 
> centos7 with stock qemu, that is in source code and 
> packaging/releases. CentOS7 will EOL until 2024 and stock support should be 
> supported until then.
>
> Regards.
>
>
>
>
> 
> From: Daniel Augusto Veronezi Salvador 
> Sent: Wednesday, March 2, 2022 2:31:21 AM
> To: dev@cloudstack.apache.org 
> Subject: Re: [VOTE] CentOS 7 KVM binaries
>
> Rohit,
>
> As we are deciding a requirement for deploying ACS + KVM + CentOS 7, I 
> see it as an important technical decision, that is why I started the 
> voting thread. The discussion was made via another thread[¹]; 
> therefore, this vote was created with the intention to summarize the 
> discussion we had and then to officially approve (or not approve) the idea 
> discussed.
>
> Finally, to emphasize, this is the voting thread, intended to reflect 
> the decision we seem to have agreed upon in the other thread[¹]. I 
> would kindly ask to avoid polluting this thread with discussions not 
> related to the voting itself. Furthermore, as already stated, there is 
> a consensus in the discussion thread; therefore, there is no harm in 
> giving a +1 here.
>
> Best regards,
> Daniel Salvador
>
> [¹] https://lists.apache.org/thread/z7s0774n72v4o9dnl140wvm030bxovjd
>
> On 01/03/2022 16:56, Rohit Yadav wrote:
> > (phone issue sent draft accidentally)... where consensus is built
> without opposition. Therefore this vote thread isn't necessary.
> >
> > Refer to project bylaws https://cloudstack.apache.org/bylaws.html
> >
> > Regards.
> > 
> > From: Daniel Augusto Veronezi Salvador 
> > Sent: Tuesday, March 1, 2022 5:08:55 PM
> > To: dev@cloudstack.apache.org 
> > Subject: Re: [VOTE] CentOS 7 KVM binaries
> >
> > Hi, Andrija and Paul,
> >
> > This is the vote thread, not the discussion one. The goal of this 
> > thread is to account votes to verify the agreement of the community 
> > with the proposed solution that we seem to have in the discussion 
> > thread. For discussions, please refer to the discussion thread[¹].
> > The goal is to collect +1 and -1 to show the community agreement 
> > with the proposal that we discussed.
> >
> > Best regards,
> > Daniel Salvador
> >
> >
> > [¹] https://lists.apache.org/thread/z7s0774n72v4o9dnl140wvm030bxovjd
> >
> >
> > On 28/02/2022 20:04, Andrija Panic wrote:
> >> What Paul said...
> >>
> >
> >
> >
>
>
> > On Mon, 28 Feb 2022 at 22:01, Paul Angus  wrote:
> >>
> >>> A vote really isn't required for this.
> >>>
> >>> No one disagrees, so just do it.
> >>>
> >>>
> >>>
> >>> Kind Regards
> >>>
> >>>
> >>> Paul Angus
> >>>
> >>> -Original Message-
> >>> From: Wei ZHOU 
> >>> Sent: Monday, February 28, 2022 4:19 PM
> >>> To: dev@cloudstack.apache.org
> >>> Subject: Re: [VOTE] CentOS 7 KVM binaries
>

RE: [VOTE] CentOS 7 KVM binaries

[Paul Angus]

A vote really isn't required for this.

No one disagrees, so just do it.



Kind Regards


Paul Angus

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

+1 (binding)

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

-Wei

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

> Hi all, this is the vote thread that emerged from the thread 
> "[Discussion] CentOS 7 KVM binaries"[¹].
>
> As discussed in the thread, users already install (without any 
> official guide provided by the community) the qemu-kvm-ev binary in 
> their environments to run CloudStack + CentOS + KVM with all features.
>
> With that said, to solve the situation described in the discussion 
> thread[¹], I propose the following:
>
> - On CloudStack's Installation Guide > Host KVM Installation[²], we 
> add a section guiding users to install the qemu-kvm-ev binaries, if 
> they are using CentOS 7.
>   - The packages that we will guide users to install will be the 
> latest provided by the official CentOS site[³] (the current latest 
> version is '2.12.0-44.1.el7_8.1.x86_64').
>
> For sanity in tallying the vote, can PMC members please be sure to 
> indicate "(binding)" with their vote?
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> If this gets approved, I'll open a PR on CloudStack Documentation 
> repository[⁴].
>
>
> Best regards,
> Daniel Salvador
>
>
> [¹] https://lists.apache.org/thread/z7s0774n72v4o9dnl140wvm030bxovjd
> [²]
>
> http://docs.cloudstack.apache.org/en/latest/installguide/hypervisor/kv
> m.html [³] 
> http://mirror.centos.org/centos-7/7/virt/x86_64/kvm-common/Packages/q/
> [⁴] https://github.com/apache/cloudstack-documentation
>

RE: [ANNOUNCE] New committer: Ivet Petrova

[Paul Angus]

Congratulations Ivet!

Kind Regards


Paul Angus

-Original Message-
From: Pearl d'Silva  
Sent: Wednesday, December 22, 2021 4:41 AM
To: dev@cloudstack.apache.org
Subject: Re: [ANNOUNCE] New committer: Ivet Petrova

Congratulations Ivet!

Regards,
Pearl Dsilva

From: Nicolas Vazquez 
Sent: Wednesday, December 22, 2021 1:00 AM
To: dev@cloudstack.apache.org 
Subject: Re: [ANNOUNCE] New committer: Ivet Petrova

Congratulations Ivet!

Regards,
Nicolas Vazquez

From: Gabriel Beims Bräscher 
Sent: Tuesday, December 21, 2021 9:48:11 AM
To: dev 
Subject: [ANNOUNCE] New committer: Ivet Petrova

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

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

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

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

--
Gabriel Beims Bräscher
Apache CloudStack PMC Chair




 

RE: [ANNOUNCE] New committer: Slavka Peleva

[Paul Angus]

Congrats Slavka.

Kind Regards


Paul Angus

-Original Message-
From: Pearl d'Silva  
Sent: Wednesday, December 22, 2021 4:42 AM
To: dev@cloudstack.apache.org
Subject: Re: [ANNOUNCE] New committer: Slavka Peleva

Congratulations Slavka!

Regards,
Pearl Dsilva

From: Nicolas Vazquez 
Sent: Wednesday, December 22, 2021 1:01 AM
To: dev@cloudstack.apache.org 
Subject: Re: [ANNOUNCE] New committer: Slavka Peleva

Congratulations Slavka!

Regards,
Nicolas Vazquez

From: Gabriel Beims Bräscher 
Sent: Tuesday, December 21, 2021 9:48:40 AM
To: dev 
Subject: [ANNOUNCE] New committer: Slavka Peleva

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

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

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

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

--
Gabriel Beims Bräscher
Apache CloudStack PMC Chair




 

RE: Live migration between AMD Epyc and Ubuntu 18.04 and 20.04

[Paul Angus]

gt; > are seeing. Precisely at Ubuntu's bug #*1887490*
> > > <https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1887490>:
> > > https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1887490
> > >
> > > In the link above, there was the following comment:
> > >
> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1887490/comments/5
> 3
> > >
> > > It seems one of the patches also introduced a regression:* 
> > > lp-1887490-cpu_map-Add-missing-AMD-SVM-features.patchadds various 
> > > SVM-related flags. Specifically npt and nrip-save are now expected 
> > > to
> be
> > > present by default as shown in the updated testdata.This however 
> > > breaks migration from instances using *EPYC* or *EPYC-IBPB* CPU 
> > > models started with libvirt versions prior to this one because the 
> > > instance on the
> > target
> > > host has these extra flags
> > >
> > >
> > > More about #*1887490*
> > > <https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1887490> can 
> > > be
> > found
> > > at the mail
> > >
> >
> https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg5842376.html.
> > > We can see that the specific bug was addressed in "linux 
> > > (5.4.0-49.53) focal".
> > >
> > > linux (5.4.0-49.53) focal; urgency=medium
> > >
> > >   * Add/Backport EPYC-v3 and EPYC-Rome CPU model (LP: #1887490)
> > > - kvm: svm: Update svm_xsaves_supported
> > >
> > >
> > > Regards,
> > > Gabriel.
> > >
> > > On Fri, Dec 3, 2021 at 10:59 AM Paul Angus <
> paul.an...@ticketmaster.com>
> > > wrote:
> > >
> > > > Which version(s) of QEMU are you using Wido?
> > > >
> > > > We've just be upgrading CentOS 7.6 to 7.9 Most 7.6 hosts had 
> > > > qemu-ev 2.10 on it  (the buggy one). 2.12 was on
> the
> > > > new hosts.
> > > > We were getting errors complaining that the ibpb CPU feature 
> > > > wasn't available when migrating to the updated OS hosts (even 
> > > > though
> identical
> > > > hardware).
> > > >
> > > > Upgrading qemu-ev to 2.12 on the originating host, then stopping 
> > > > and starting the VMs, then allowed us to migrate.  We couldn't 
> > > > find any solution that didn't involve stopping and starting the VMs.
> > > >
> > > > Paul.
> > > >
> > > > -Original Message-
> > > > From: Wido den Hollander 
> > > > Sent: Monday, November 29, 2021 7:57 AM
> > > > To: dev@cloudstack.apache.org; Wei ZHOU 
> > > > Subject: Re: Live migration between AMD Epyc and Ubuntu 18.04 
> > > > and
> 20.04
> > > >
> > > >
> > > >
> > > > On 11/24/21 10:36 PM, Wei ZHOU wrote:
> > > > > Hi Wido,
> > > > >
> > > > > I think it is not good to run an environment with two 
> > > > > ubuntu/qemu
> > > > versions.
> > > > > It always happens that some cpu features are supported in the
> higher
> > > > > version but not supported in the older version.
> > > > > From my experience, the migration from older version to higher
> > version
> > > > > works like a charm, but there were many issues in migration 
> > > > > from higher version to older version.
> > > > >
> > > >
> > > > I understand. But with a large amount of hosts and working your 
> > > > way through upgrades you sometimes run into these situations. 
> > > > Therefor it
> > > would
> > > > be welcome if it works.
> > > >
> > > > > I do not have a solution for you. I have tried to hack 
> > > > > /etc/libvirt/hooks/qemu but it didn't work.
> > > > > Have you tried with other cpu models like x86_Opteron_G5 ? you 
> > > > > can find the cpu features of each cpu model in
> > /usr/share/libvirt/cpu_map/
> > > > >
> > > >
> > > > I have not tried that yet, but I can see if that works.
> > > >
> > > > The EPYC-IBPB CPU model is identical on 18.04 and 20.04, but 
> > > > even
> using
> > > > that model we can't seem to migrate as it complains about the 'npt'
> > > feature.
> > > >
> > > > Wido
> > > >
> > > >

RE: Live migration between AMD Epyc and Ubuntu 18.04 and 20.04

[Paul Angus]

Which version(s) of QEMU are you using Wido?

We've just be upgrading CentOS 7.6 to 7.9
Most 7.6 hosts had qemu-ev 2.10 on it  (the buggy one). 2.12 was on the new 
hosts.
We were getting errors complaining that the ibpb CPU feature wasn't available 
when migrating to the updated OS hosts (even though identical hardware).

Upgrading qemu-ev to 2.12 on the originating host, then stopping and starting 
the VMs, then allowed us to migrate.  We couldn't find any solution that didn't 
involve stopping and starting the VMs.

Paul.

-Original Message-
From: Wido den Hollander 
Sent: Monday, November 29, 2021 7:57 AM
To: dev@cloudstack.apache.org; Wei ZHOU 
Subject: Re: Live migration between AMD Epyc and Ubuntu 18.04 and 20.04



On 11/24/21 10:36 PM, Wei ZHOU wrote:
> Hi Wido,
>
> I think it is not good to run an environment with two ubuntu/qemu versions.
> It always happens that some cpu features are supported in the higher
> version but not supported in the older version.
> From my experience, the migration from older version to higher version
> works like a charm, but there were many issues in migration from
> higher version to older version.
>

I understand. But with a large amount of hosts and working your way through 
upgrades you sometimes run into these situations. Therefor it would be welcome 
if it works.

> I do not have a solution for you. I have tried to hack
> /etc/libvirt/hooks/qemu but it didn't work.
> Have you tried with other cpu models like x86_Opteron_G5 ? you can
> find the cpu features of each cpu model in /usr/share/libvirt/cpu_map/
>

I have not tried that yet, but I can see if that works.

The EPYC-IBPB CPU model is identical on 18.04 and 20.04, but even using that 
model we can't seem to migrate as it complains about the 'npt' feature.

Wido

> Anyway, even if the vm migration succeeds, you do not know if vm works
> fine. I believe the best solution is upgrading all hosts to the same
> OS version.
>
> -Wei
>
> On Tue, 23 Nov 2021 at 16:31, Wido den Hollander  wrote:
>
>> Hi,
>>
>> I'm trying to debug an issue with live migrations between Ubuntu
>> 18.04 and 20.04 machines each with different CPUs:
>>
>> - Ubuntu 18.04 with AMD Epyc 7552 (Rome)
>> - Ubuntu 20.04 with AMD Epyc 7662 (Milan)
>>
>> We are currently using this setting:
>>
>> guest.cpu.mode=custom
>> guest.cpu.model=EPYC
>>
>> This does not allow for live migrations:
>>
>> Ubuntu 20.04 with Epyc 7662 to Ubuntu 18.04 with Epyc 7552 fails
>>
>> "ExecutionException : org.libvirt.LibvirtException: unsupported
>> configuration: unknown CPU feature: npt"
>>
>> So we tried to define a set of features manually:
>>
>> guest.cpu.features=3dnowprefetch abm adx aes apic arat avx avx2 bmi1
>> bmi2 clflush clflushopt cmov cr8legacy cx16 cx8 de f16c fma fpu
>> fsgsbase fxsr fxsr_opt lahf_lm lm mca mce misalignsse mmx mmxext
>> monitor movbe msr mtrr nx osvw pae pat pclmuldq pdpe1gb pge pni
>> popcnt pse pse36 rdrand rdseed rdtscp sep sha-ni smap smep sse sse2
>> sse4.1 sse4.2 sse4a
>> ssse3 svm syscall tsc vme xgetbv1 xsave xsavec xsaveopt -npt -x2apic
>> -hypervisor -topoext -nrip-save
>>
>> This results in this going into the XML:
>>
>> 
>>
>> You would say that works, but then the target host (18.04 with the
>> 7552) says it doesn't support the feature 'npt' and the migration still 
>> fails.
>>
>> Now we could ofcourse use the kvm64 CPU from Qemu, but that's lacking
>> so many features that for example TLS offloading isn't available.
>>
>> I also tried to set 'EPYC-Rome' on the Ubuntu 20.04 hypervisor, but
>> it then complains on the Ubuntu 18.04 hypervisor that the CPU 'EPYC-Rome'
>> is unknown as the 18.04 hypervisor doesn't have that profile.
>>
>> Any ideas on how to get this working?
>>
>> Wido
>>
>
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: Docker images

[Paul Angus]

 

‘Official’ CloudStack docker images should be published via the Apache org 
account.  They’ll have all the payment stuff sorted 

 

 

 

 

Kind Regards

 

 

Paul Angus

 

From: Sina Kashipazha  
Sent: Monday, November 22, 2021 10:25 AM
To: Wei ZHOU 
Cc: dev@cloudstack.apache.org
Subject: Re: Docker images

 

Hey again,

 

I've checked that, Docker CE and Docker CLI are still free ;)

 

Kind regards,

Sina

 

‐‐‐ Original Message ‐‐‐

On Monday, November 22nd, 2021 at 11:05, Sina Kashipazha 
mailto:s.kashipa...@protonmail.com.INVALID> > wrote:

 

Hey Wei,

 

I couldn't find anything on their website regarding the CLI usage. It seems 
that they have changed the license only for desktop.

 

Kind regards,

Sina

 

‐‐‐ Original Message ‐‐‐

On Monday, November 22nd, 2021 at 10:47, Wei ZHOU mailto:ustcweiz...@gmail.com> > wrote:

 

Hi Sina,

 

Thanks for the heads up. It seems the new policy is applicable for Docker 
Desktop only. We can still use Docker CLI for free, Right ?

 

-Wei

 

On Mon, 22 Nov 2021 at 10:30, Sina Kashipazha 
mailto:s.kashipa...@protonmail.com.invalid> > wrote:

Hey,

BTW, it is worth mentioning that Docker has changed its subscription policy. If 
you are a company with more than $10 million in annual revenue, you have to 
upgrade to the business account. I quoted the following paragraph from their 
FAQ. I'm not clear if it has any effects on open source usage or not.

How will Docker enforce the new subscription terms for Docker Desktop?
Docker trusts our customers to be in compliance by January 31, 2022. Docker 
Desktop will continue to function normally after January 31st but unpaid 
commercial use by companies over 250 employees OR $10 million in annual revenue 
will be in violation of the Docker Subscription Service Agreement.

More info: https://www.docker.com/pricing/faq

Kind regards,
Sina

‐‐‐ Original Message ‐‐‐

On Thursday, November 18th, 2021 at 19:53, Wei ZHOU mailto:ustcweiz...@gmail.com> > wrote:

> Agrees.
> 

> There are many users using docker, but for different goals. Depends on
> 

> requirements, the solutions are also different.
> 

> 1.  What OS ?
> 2.  Use docker for packaging , demo or testing changes ?
> 3.  Are packages ready ? official releases, nightly build or need to build
> 

> packages from source code ?
> 4.  Is mysql or madiadb cluster installed in the docker or external?
> 5.  use simulator or physical resources ?
> 

> Currently the all-in-1 docker image built from tools/docker/Dockerfile 
> just
> 

> works for me.
> 6.  Ubuntu 20.04
> 7.  demo or testing code changes
> 8.  Build packages from source
> 9.  Mysql is installed in docker image
> 10.  Simulator is supported. Did not use physical resources yet but it seems
> 

> not to be an issue.
> 

> We can consider using separated docker images, for example 1 for 
> packaging,
> 

> 1 or 3 for db, 1 or 3 for management servers. It is more flexible. We can
> 

> use docker-compose, swarm, or kubernetes to setup such an environment.
> 

> -Wei
> 

> On Wednesday, 17 November 2021, Marcus shadow...@gmail.com 
> <mailto:shadow...@gmail.com>  wrote:
> 

> > Cool, we are on the same page there. I think I have something working to
> > 

> > share soon.
> > 

> > I did also consider just installing RPMs or DEBs into a Docker image like a
> > 

> > standard install, which might be a good pattern for official releases so we
> > 

> > can rely on the same package dependency resolution for all of the
> > 

> > requirements.
> > 

> > For development it is extra work to set up the packaging environment and
> > 

> > more time to run the RPM/DEB package process every time you want to try a
> > 

> > build but that’s still an option as well. Right now I’m just copying the
> > 

> > necessary files into a new Docker image stage like you might do in an RPM
> > 

> > spec.
> > 

> > I feel like I also ran into an issue with some hard coding for x86_64 in
> > 

> > regards to the RPMs, which a direct build and package into Dockerfile
> > 

> > avoided.
> > 

> > On Wednesday, November 17, 2021, Wei ZHOU ustcweiz...@gmail.com 
> > <mailto:ustcweiz...@gmail.com>  wrote:
> > 

> > > Hi Marcus,
> > > 

> > > Sometimes I use the docker images to build a simulator environment. the
> > > 

> > > docker images are built from tools/docker/Dockerfile
> > > 

> > > I have uploaded some images to
> > > 

> > > https://hub.docker.com/repository/docker/ustcweizhou/
> > > 

> > >

RE: Docker images

[Paul Angus]

Hi Marcus et al,

This is where I had got to, to a create a containerised image of simulator, 
with options to deploy a region created by marvin (either a predetermined 
multi-zone one or a user defined one)

It was based on the premise of as few layers as possible, all as small as 
possible.  (and it was for 4.14)

https://github.com/PaulAngus/docker-simulator

caveat emptor - its not finished and there are some lines that were just for 
debugging in there

There may be some ideas that are worth cherry-picking from in there.



Kind Regards


Paul Angus

-Original Message-
From: Marcus  
Sent: Wednesday, November 17, 2021 3:25 PM
To: dev@cloudstack.apache.org
Subject: Re: Docker images

Cool, we are on the same page there. I think I have something working to share 
soon.

I did also consider just installing RPMs or DEBs into a Docker image like a 
standard install, which might be a good pattern for official releases so we can 
rely on the same package dependency resolution for all of the requirements.

For development it is extra work to set up the packaging environment and more 
time to run the RPM/DEB package process every time you want to try a build but 
that’s still an option as well. Right now I’m just copying the necessary files 
into a new Docker image stage like you might do in an RPM spec.

I feel like I also ran into an issue with some hard coding for x86_64 in 
regards to the RPMs, which a direct build and package into Dockerfile avoided.

On Wednesday, November 17, 2021, Wei ZHOU  wrote:

> Hi Marcus,
>
> Sometimes I use the docker images to build a simulator environment. 
> the docker images are built from tools/docker/Dockerfile I have 
> uploaded some images to 
> https://hub.docker.com/repository/docker/ustcweizhou/cloudstack-simula
> tor
>
> The docker images are very large indeed (1.78 GB after compression). I 
> think it is because of two reasons
> (1) a jetty server is running , which requires the build of whole 
> project
> (2.0 GB, including .java, .class and .jar)
> (2) run UI via `npm start` which it requires some npm components 
> (~600GB in
> ui/node_modules/)
>
> I was thinking of installing cloudstack-management and cloudstack-ui 
> instead of running jetty/UI from source code.
> I finally gave it up because there is no package for cloudstack 
> simulator on ubuntu 20.04 ( as said I normally use it for simulator).
>
> -Wei
>
> On Tue, 9 Nov 2021 at 18:15, Marcus  wrote:
>
> > Hi all, I've been familiarizing myself with the Docker image tooling 
> > in CloudStack, and I have a few questions.  I've been playing with a 
> > multi-stage build that shrinks the image from ~4Gi to ~800Mi, 
> > packages
> just
> > the jar, some UI, and a JDK thinking that it might be more usable.
> >
> > 1) Is there anyone actively using these Dockerfiles? It might be 
> > interesting to know what workflows they're a part of and whether 
> > they can be changed or if new files should be created.
> >
> > 2) I see the Dockerfile.marvin points to a 'builds.cloudstack.org' 
> > to
> pull
> > a Marvin bundle, which seems to be down.  Do these artifacts need to 
> > be moved to 'download.cloudstack.org' or is this just a temporary 
> > outage,
> or
> > is it only reachable from CI? I do see the 'latest' tag pulls (which 
> > is three years old).
> >
>

RE: Local simulation of Apache Cloudstack instances/API endpoints: state of the art, target groups and use cases

[Paul Angus]

Hi Peter,

I need to get round to polishing a dockerfile that would create an image to
be run as a CloudStack simulator in a container (or if there's enough
interest I could share it's current state for others to finish).

But. If you want to work on real world integrations, I'd guess that you
would likely to need real hosts to create VMs on. Trillian
(https://github.com/shapeblue/trillian) was created for the exact purpose
that you are describing.   In fact it runs most of the automated testing
done on CloudStack. And can support 10s even 100s of concurrent
environments.

I'm not going to lie - it takes a bit of setting up (and isn't local) - but
it's run thousands of times creating environments for testing business logic
and integrations


Regards

Paul Angus


-Original Message-
From: Muryshkin, Peter  
Sent: Thursday, October 21, 2021 11:30 AM
To: dev@cloudstack.apache.org; us...@cloudstack.apache.org
Subject: Local simulation of Apache Cloudstack instances/API endpoints:
state of the art, target groups and use cases

Hi all,

from what I can find, there are  three more or less established/already well
elaborated approaches to simulate a CloudStack instance locallly.
Depending on the target group and their goals, they can have different
levels of fidelity and usability.

1. Obviously CloudStack developers confgure a KVM development environment to
work inside it, this is part of the Apache CloudStack Hackerbook kindly
shared by ShapeBlue. [1] 2. For test scenarios, Hackerbook describes a
mocked simulator approach [2] 3. For users for whom the whole cloud system
is just a "black box", especially cloud beginners, there is a single
integrated Docker container. [3]

With the rise of CI/CD and infrastructure as code automation practices,
where you just need more or less on demand one or even many versions of the
CloudStack API,  [3] appears to be a crucial building block in the cloud
userspace before just "trying out CloudStack".

So it appears that there might be much demand on a Apache CloudStack
containerized instance:

1. Demand from potential new adopters, for their "Apache CloudStack to go"
demos 2. Demand from DevOps/GitOps/SRE/you-name-it enabled teams who
implement their virtual infrastructure for example with Terraform and the
CloudStack provider plugin and want to simulate rollout scenarios.

However, is this true?

* the container simulator hasn't been updated on DockerHub since a couple of
years; is there another place in meantime or will this approach dumped for
some reason?
* there is not so much discussion about this asset on mailing lists; so
there is not so much demand as one might assume?

What do you think?

kind regards

--

Peter Muryshkin
Fraunhofer Gesellschaft
https://www.linkedin.com/in/muryshkin/

RE: [VOTE] Apache Cloudstack 4.16.0.0 RC1

[Paul Angus]

Thanks Daniel,

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

Kind Regards


Paul Angus

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

Paul,


Noredist packages are only necessary to VMWare.

KVM/XenServer infrastructures don't use noredist packages.


Best regards,
Daniel Salvador

On 20/10/2021 12:29, Paul Angus wrote:
> I vaguely thought that the VMware jars come under a compatible license these 
> days, so don't need to be noredist anymore?
>
>
> -Original Message-
> From: Daniel Augusto Veronezi Salvador 
> Sent: Wednesday, October 20, 2021 2:53 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Apache Cloudstack 4.16.0.0 RC1
>
> Hi Nicolas, thanks for the work.
>
> I started testing this RC and unfortunately I ran into some problems related 
> to building/upgrading ACS.
>
>   From the less to the more complex:
>
> - When building ".deb", there is a problem with the Debian changelog:
> invalid weekday 'lun';
>
> - Regarding auto upgrading "systemvms-templates", I analyzed the code and 
> concluded that "systemvms-templates" will only "autoupgrade" if we use the 
> profile "noredist" when building the packages, which is necessary only to 
> VMWare. Some people, might not want the noredist JARs, and therefore will not 
> build with this profile. With that said, there are some points regarding it 
> that I think are important:
>  - Package "cloudstack-management" goes from ~100Mb to more than 1.5Gb, 
> when using "noredist" while executing the 4.16.0.0 build. It happens due to 
> "cloudstack/engine/schema/pom.xml" automatically downloading XenServer, KVM, 
> and VMware "systemvms-templates". Every time that we build the packages, it 
> will download all these systemvms-templates; we are unable to decide which 
> one is necessary or not. If we do not use XenServer, or other hypervisors, 
> why download it?
>  - If we build the packages with "noredist", when we are first running 
> ACS after upgrading it to 4.16, it will try to autoupgrade the 
> systemvms-templates, however, some KVM/XenServer infrastructures don't allow 
> the management server to access the secondary storage directly (except for 
> the first systemvm-template seed). This will cause
> "mount.nfs: access denied by server while mounting ".
> After generating this error, ACS continues the upgrade and updates the 
> database; however, the new systemvm-template will not be in the secondary 
> storage. If we try to deploy a system (like virtual router), it will fail (as 
> expected).
>  - I rolled back my environment to 4.15, did a manual seed of 
> systemvmtemplate-4.16.0-kvm.qcow2.bz2, built the packages without "noredist" 
> and tried to upgrade the environment to 4.16. Then, ACS automatically tried 
> to upgrade the systemvm-templates; even though the system VM template for 
> 4.16 is already there, it throws some errors:
>
> 2021-10-19 23:08:02,684 DEBUG [c.c.u.d.Upgrade41520to41600] (main:null)
> (logid:) Updating System Vm template IDs
> 2021-10-19 23:08:02,904 DEBUG [c.c.u.SystemVmTemplateRegistration]
> (main:null) (logid:) Updating System Vm template IDs
> 2021-10-19 23:08:02,910 DEBUG [c.c.u.SystemVmTemplateRegistration]
> (main:null) (logid:) Updating VMware System Vms
> 2021-10-19 23:08:02,915 WARN  [c.c.u.SystemVmTemplateRegistration]
> (main:null) (logid:) 4.16.0 VMware SystemVm template not found. Cannot 
> upgrade system Vms hypervisor is not used, so not failing upgrade
> 2021-10-19 23:08:02,962 DEBUG [c.c.u.SystemVmTemplateRegistration]
> (main:null) (logid:) Updating KVM System Vms
> 2021-10-19 23:08:02,966 INFO  [c.c.u.SystemVmTemplateRegistration]
> (main:null) (logid:) Grabbing lock to register templates.
> 2021-10-19 23:08:02,976 ERROR [c.c.u.SystemVmTemplateRegistration]
> (main:null) (logid:) Failed to calculate template checksum
> java.nio.file.NoSuchFileException:
> /usr/share/cloudstack-management/templates/systemvm/systemvmtemplate-4.16.0-kvm.qcow2.bz2
>   at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
>   at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
>   at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
>   at
> java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:219)
>   at java.base/java.nio.file.Files.newByteChannel(Files.java:371)
>   at java

RE: [VOTE] Apache Cloudstack 4.16.0.0 RC1

[Paul Angus]

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


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

Hi Nicolas, thanks for the work.

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

 From the less to the more complex:

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

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

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

RE: Hi (Again)

[Paul Angus]

Thanks - it was good to find role with a chunk of CloudStack in it.



Kind regards

Paul Angus

-Original Message-
From: Andrija Panic  
Sent: 13 September 2021 14:39
To: dev 
Subject: Re: Hi (Again)

Welcome back, Paul :)

On Mon, 13 Sept 2021 at 14:40, Rohit Yadav 
wrote:

> Paul,
>
> Until the proper feature/changes are in, to pass any arbitrary 
> param/values to an API you can simply add them in the UI/URL.
>
> For example, as root admin:
> http://qa.cloudstack.cloud:8080/client/#/vm returns 11 VMs 
> http://qa.cloudstack.cloud:8080/client/#/vm?projectid=-1=true
> returns 14 VMs (including all projects)
>
>
> Regards.
>
> 
> From: Pearl d'Silva 
> Sent: Monday, September 13, 2021 18:06
> To: dev@cloudstack.apache.org 
> Subject: Re: Hi (Again)
>
> Hi Paul,
>
> There's another PR inflight aiming towards achieving something similar:
> https://github.com/apache/cloudstack/pull/5207.
>
> Regards,
> Pearl
> 
> From: Paul Angus 
> Sent: Monday, September 13, 2021 5:23 PM
> To: dev@cloudstack.apache.org 
> Subject: RE: Hi (Again)
>
> Hi David,
>
> Harsh - But probably true
>
> Thanks for the link!
>
> Kind regards
>
> Paul Angus
>
>
>
>
>
>
>
> -Original Message-
> From: David Jumani 
> Sent: 13 September 2021 12:46
> To: dev@cloudstack.apache.org
> Subject: Re: Hi (Again)
>
> 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.
>
>
>
>

-- 

Andrija Panić

RE: Hi (Again)

[Paul Angus]

Hi David,

Harsh - But probably true

Thanks for the link!

Kind regards

Paul Angus

-Original Message-
From: David Jumani  
Sent: 13 September 2021 12:46
To: dev@cloudstack.apache.org
Subject: Re: Hi (Again)

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.

 

Hi (Again)

[Paul Angus]

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: [Discussion] Release Cycle

[Paul Angus]

Gabriel,

FYI  point 2 is covered in the community bylaws (Section 3.4.3)

3.4.3. Release Plan
- Defines the timetable and work items for a release. The plan also nominates a 
Release Manager.
- A lazy majority of active committers is required for approval.
- Any active committer or PMC member may call a vote. The vote must occur on 
the project development mailing list.

On point 1, "...a roadmap would be defined to guide the community through the 
year." Is this something ridged or a fluid list of things people think they'll 
be putting in as they go along?

Also, you haven't covered WHO is doing these releases that the community is 
committing to.  Otherwise a +1 means that the voter was committing themselves 
to working on the release.

3.1.2. Voting may take four flavors:
  3.1.2.1.+1 "Yes," "Agree," or "the action should be performed." In 
general, this vote also indicates a willingness on the behalf of the voter in 
"making it happen"
  

http://cloudstack.apache.org/bylaws.html



Kind regards

Paul Angus

-Original Message-
From: Gabriel Bräscher  
Sent: 10 September 2021 14:15
To: dev 
Subject: Re: [Discussion] Release Cycle

Hi all,

Looks like we are moving forward and raising important points.
Summing some key factors pointed in this discussion:
- CloudStack is getting stable.
- From the developers' side, the costs of releasing and maintaining an LTS are 
high. There is a "human" limitation in terms of how many releases the community 
can spin per year.
- From the users' perspective, upgrading CloudStack infrastructures has its 
costs (Pierre also raised this and I totally agree). Many users end up 
upgrading their infra once a year (or once in 2 years).

With that said, I would like to propose the following:
1. The project compromises in having 1 LTS per year, and eventually one 1 
Regular. For that, a roadmap would be defined to guide the community through 
the year.
2. It should be no problem to have an "extra" release in a specific year.
For that, a volunteer would propose such release raising the reasons behind it. 
Each "extra" release proposed would require a VOTE.

Please let me know if the proposed points look good. If that's the case, then I 
will move forward to present a draft to be added to the wiki.
If you think it would be better to kick a separate VOTE thread for it I can 
also raise it.

Regards,
Gabriel.

Em qui., 9 de set. de 2021 às 07:52, Rohit Yadav 
escreveu:

> Hi Gabriel,
>
> Agree with your conclusion - let's go with (at least) two major 
> releases in a year.
>
> I would add that there's no real logistical difference between a 
> regular vs LTS release, so for example someone could propose and work 
> on a "regular" release but it can become LTS if there are 
> volunteers/contributors who want to maintain a release. That said - by 
> all means just go ahead, propose and do release management!
>
> ps. And on a ".0" being stable I suppose it is somewhat stable in last 
> few years as we've got our CI/CD systems quite robust for a subset of 
> smoketests, all our releases thankfully at least go through a round of 
> smoketests across three hypervisors - that is not to say no release 
> has no reported issues (in fact they all do ).
>
>
> Regards.
>
> 
> From: Gabriel Bräscher 
> Sent: Wednesday, September 8, 2021 18:39
> To: dev 
> Subject: Re: [Discussion] Release Cycle
>
> Thanks all for helping with the discussion.
>
> Yes, Rohit. I need to answer a few pings, sorry for the delay :-) I 
> totally agree with you and Paul, the costs of releasing are high, 
> especially for the release manager(s) which dedicates a lot of energy 
> and time to it.
> This is one of the reasons behind this discussion; when we formalize 
> and document the release pace it is easier to plan a year knowing how 
> things will roll out, from the perspective of RMs, devs, or users.
>
> Going in the same direction as Rohit, I also agree that we are getting 
> each year stabler, maybe one LTS per year is better than the current pace of 
> 2.
> Therefore, I would propose 1 LTS and 1 Regular per year; I see it as a 
> good balance between stability and agility.
> Additionally, most users do not upgrade from an LTS to another twice a 
> year, it takes time to plan and execute such tasks (and they always 
> have some risks).
> From my experience, an LTS per year would perfectly match the needs of 
> most users.
>
> I do understand that many adopt ".0" as an "unstable"/"Regular" LTS.
> However, I don't think this is the best approach.
> Additionally, many users do not see a ".0" LTS (which is how we brand 
> in documentation, website, and release announcement) as a 

RE: [ANNOUNCE] Nicolas Vazquez has joined the PMC

[Paul Angus]

Congrats Nicolas



Kind regards

Paul Angus

-Original Message-
From: Andrija Panic  
Sent: Thursday, August 5, 2021 9:18 PM
To: dev 
Subject: Re: [ANNOUNCE] Nicolas Vazquez has joined the PMC

Another one bites the dust...

;)

On Wed, 4 Aug 2021 at 08:27, Abhishek Kumar 
wrote:

> Congrats Nicolas!
> 
> From: Gabriel Beims Bräscher 
> Sent: 03 August 2021 00:58
> 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
>
>
>
>

-- 

Andrija Panić

RE: Triage Permission

[Paul Angus]

+1

Don't forget to include a link in Pony Mail [1] of the 'agreement' to the 
request

[1] https://lists.apache.org/list.html?dev@cloudstack.apache.org


Kind regards

Paul Angus

-Original Message-
From: Daan Hoogland  
Sent: Monday, July 19, 2021 11:12 AM
To: dev 
Subject: Re: Triage Permission

yes you may @Spaceman1984 (binding?) please create an infra ticket for it.

On Mon, Jul 19, 2021 at 11:59 AM Darrin Hüsselmann < 
darrin.husselm...@shapeblue.com> wrote:

> Hi Guys,
>
> May I please have the triage permission on the 
> cloudstack-documentation 
> repo<https://github.com/apache/cloudstack-documentation> for Spaceman1984?
>
> Cheers,
> Darrin

RE: [ANNOUNCE] New committer: Daniel Augusto Veronezi Salvador

[Paul Angus]

Congratulation Daniel!



Kind regards

Paul Angus

-Original Message-
From: Sven Vogel  
Sent: 07 July 2021 10:59
To: dev@cloudstack.apache.org
Subject: AW: [ANNOUNCE] New committer: Daniel Augusto Veronezi Salvador

Congratulation Daniel!

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

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: Wei ZHOU 
Datum: Mittwoch, 7. Juli 2021 um 10:28
An: dev@cloudstack.apache.org 
Betreff: Re: [ANNOUNCE] New committer: Daniel Augusto Veronezi Salvador 
Congratulations Daniel !

-Wei


On Tue, 6 Jul 2021 at 19:21, Gabriel Beims Bräscher 
wrote:

> The Project Management Committee (PMC) for Apache CloudStack has 
> invited Daniel to become a committer and we are pleased to announce 
> that the contributor has accepted.
>
> Please join me in congratulating Daniel on this accomplishment.
>
> Being a committer enables easier contribution to the project since 
> there is no need to go via the patch submission process. This should 
> enable better productivity.
> Being a PMC member enables assistance with the management and to guide 
> the direction of the project.
>
> --
> Gabriel Beims Bräscher
> Apache CloudStack PMC Chair
>

RE: [ANNOUNCE] New committer: Pearl DSilva

[Paul Angus]

Congratulation Pearl!



Kind regards

Paul Angus

-Original Message-
From: Sven Vogel  
Sent: 07 July 2021 10:58
To: dev@cloudstack.apache.org
Subject: AW: [ANNOUNCE] New committer: Pearl DSilva

Congratulation Pearl!

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

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: Wei ZHOU 
Datum: Mittwoch, 7. Juli 2021 um 10:28
An: dev@cloudstack.apache.org 
Betreff: Re: [ANNOUNCE] New committer: Pearl DSilva Congratulations Pearl !

-Wei

On Tue, 6 Jul 2021 at 19:21, Gabriel Beims Bräscher 
wrote:

> The Project Management Committee (PMC) for Apache CloudStack has 
> invited Pearl to become a committer and we are pleased to announce 
> that the contributor has accepted.
>
> Please join me in congratulating Pearl on this accomplishment.
>
> Being a committer enables easier contribution to the project since 
> there is no need to go via the patch submission process. This should 
> enable better productivity.
> Being a PMC member enables assistance with the management and to guide 
> the direction of the project.
>
> --
> Gabriel Beims Bräscher
> Apache CloudStack PMC Chair
>

RE: [ANNOUNCE] New committer: David Jumani

[Paul Angus]

Congratulations David!



Kind regards

Paul Angus

-Original Message-
From: Sven Vogel  
Sent: 07 July 2021 10:58
To: dev@cloudstack.apache.org
Subject: AW: [ANNOUNCE] New committer: David Jumani

Congratulation David!

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

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: Wei ZHOU 
Datum: Mittwoch, 7. Juli 2021 um 10:28
An: dev@cloudstack.apache.org 
Betreff: Re: [ANNOUNCE] New committer: David Jumani Congratulations David !

-Wei


On Tue, 6 Jul 2021 at 19:21, Gabriel Beims Bräscher 
wrote:

> The Project Management Committee (PMC) for Apache CloudStack has 
> invited David to become a committer and we are pleased to announce 
> that the contributor has accepted.
>
> Please join me in congratulating David on this accomplishment.
>
> Being a committer enables easier contribution to the project since 
> there is no need to go via the patch submission process. This should 
> enable better productivity.
> Being a PMC member enables assistance with the management and to guide 
> the direction of the project.
>
> --
> Gabriel Beims Bräscher
> Apache CloudStack PMC Chair
>

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

[Paul Angus]

+1

Regards

Paul Angus

-Original Message-
From: Suresh Anaparti  
Sent: 11 May 2021 07:15
To: us...@cloudstack.apache.org; dev@cloudstack.apache.org; 
priv...@cloudstack.apache.org
Subject: Re: [VOTE] Renaming default git branch name from 'master' to 'main' 
and replace offensive words as appropriate for inclusiveness

+1 , adding my vote as well.

Regards,
Suresh


 

On 07/05/21, 2:10 PM, "Harikrishna Patnala"  
wrote:

+1  from me.

Regards,
Harikrishna

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

RE: [DISCUSS] Marvin tests interaction

[Paul Angus]

I agree with Rohit, if people want to improve mavin ux that’s fine, but keep it 
a Marvin thing.  

- Marvin outputs a file that says what passed and what failed.
- A GUI is going to need constant ongoing maintenance for it to be able to 
understand tests to give meaningful additional information on tests or add any 
appreciable value.
- It's never going to be able to actually diagnose failures - so you're going 
to have to read logs anyway.

So in summary, the cons seem to heavily outweigh the pros to me.
Maybe a very simple TUI which generates the string which is ultimately run 
might help people.

A way to generate the file that describes the configuration of zone(s) that 
Marvin will be run against might be more helpful.


-Original Message-
From: Wei ZHOU  
Sent: 30 March 2021 15:51
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Marvin tests interaction

Can it be a standalone tool with ui ?

-Wei

On Tue, 30 Mar 2021 at 16:45, Nicolas Vazquez 
wrote:

> The idea is not to rewrite the tests in Java but to improve how we 
> interact with the tests and display results. The new service/agent 
> should not be responsible for testing but to invoke the execution of 
> the requested tests. This new service, lets say for example 'marvin 
> agent' will simply receive which tests are needed to run and invoke 
> them the same way as before. Then, it could use the information in the 
> logs for individual tests to retrieve back the results to the 
> management server. I imagine it could work similarly to the VR healths 
> checks functionality
>
>
> Regards,
>
> Nicolas Vazquez
>
> 
> From: Rohit Yadav 
> Sent: Tuesday, March 30, 2021 6:17 AM
> To: dev@cloudstack.apache.org 
> Subject: Re: [DISCUSS] Marvin tests interaction
>
> Sorry all, I don't agree - the thing being tested shouldn't be 
> responsible for testing (unless it's a well-defined limited set of 
> self-testing features, for example a set of sanity/intergrity checks).
>
> Unless we're saying the service/feature is used to run tests for other
> (nested?) CloudStack environments. The other issue is (and unless the 
> idea is to re-write tests in Java) most tests are written in Python, 
> so the CloudStack plugin/service would still fork and need to run 
> Python tests somehow (directly or via a runner such as nose) or 
> explore use of Jython or Python on JVM (which may make it complex).
>
>
> Regards.
>
> 
> From: Suresh Anaparti 
> Sent: Tuesday, March 30, 2021 11:23
> To: dev@cloudstack.apache.org 
> Subject: Re: [DISCUSS] Marvin tests interaction
>
> +1, added my thoughts in the ticket. This can ease/reduce the Dev & QA
> testing efforts. Also, it's good to see the testing results in the UI 
> itself.
>
> Regards,
> Suresh
>
> On 30/03/21, 9:41 AM, "David Jumani"  wrote:
>
> +1 on the idea and on Rakesh's suggestions!
> 
> From: Rakesh v  http://www.rakeshv@gmail.com http://www.rakeshv@gmail.com>>>
> 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
>
>
>
>
> suresh.anapa...@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
>
>
>
>
> nicolas.vazq...@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 <
> nicolas.vazq...@shapeblue.com> 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
>   

Re: [DISCUSS] Renaming default git branch name from 'master' to 'main'

[Paul Angus]

Maybe we could add main immediately and depricate master immediately after the 
next full release. I'd be -1 on any longer.  Otherwise they'll _always_ be 
someone who wants 'a little bit more time'.

Kind regards



Paul Angus



From: Wei ZHOU 
Sent: Tuesday, March 30, 2021 3:57:25 PM
To: dev@cloudstack.apache.org 
Subject: Re: [DISCUSS] Renaming default git branch name from 'master' to 'main'

yeah.
It is a small change on github, but it has large impacts.
we can keep both 'main' and 'master' branches for a period of time, and
keep them sync (e.g. by cron job).

-Wei

On Mon, 29 Mar 2021 at 09:46, Rohit Yadav  wrote:

> Agree with your proposal Suresh, we need to review all endpoint/systems
> that integrate which many likely break won't work after the update, to list
> a few we need to manage post such a change:
>
>   *   Rename and push the branch and request ASF infra to change default
> branch to 'main' in Github repo settings for all the repos
>   *   Travis and Jenkins/ASF integration
>   *   Community/external CI systems that do rpm/deb packaging, UI
> building, apidocs and systemvmtemplate builds; website and project docs
> repos build jobs
>   *   Git mirrors including the ASF mirror (unless we need to do something
> different)
>   *   Update usage of 'master' branch on project website, cwiki, internal
> readme/install docs
>   *   External docs/blogs/repos/integration and 3rd party tools/libraries
> that intergrate/use/link with CloudStack
>   *   Check if Github/Git support a way to still allow pulling from
> 'master' branch which internally links to 'main' (some like of aliasing
> like
> https://stackoverflow.com/questions/549920/is-it-possible-to-alias-a-branch-in-git/549949#549949
> )
>
> Regards.
> 
> From: Simon Weller 
> Sent: Thursday, March 25, 2021 21:08
> To: dev 
> Subject: Re: [DISCUSS] Renaming default git branch name from 'master' to
> 'main'
>
> +1
> 
> From: Gabriel Beims Bräscher 
> Sent: Thursday, March 25, 2021 6:56 AM
> To: dev 
> Subject: Re: [DISCUSS] Renaming default git branch name from 'master' to
> 'main'
>
> I am +1 on migrating from 'master' to 'main' branch.
>
> We will need to update some scripts, documentations, and the releasing
> process.
>
> Regards,
> Gabriel.
>
> On Thu, Mar 25, 2021, 08:10  wrote:
>
> > Personally, I'm +1 on this change.
> >
> >
> >
> >
> > Kind regards
> >
> > Paul Angus
> >
> > -Original Message-
> > From: Suresh Anaparti 
> > Sent: Thursday, March 25, 2021 9:23 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] Renaming default git branch name from 'master' to
> > 'main'
> >
> > Yes Wei, all the integrated systems / scripts (using the CloudStack git
> > repositories) have to replace the default branch name to 'main' wherever
> > applicable.
> >
> > Regard
> > Suresh
> >
> > On 25/03/21, 2:44 PM, "Wei ZHOU"  wrote:
> >
> > Will it impact jenkins/travis/trillian and prs ?
> >
> > -Wei
> >
> > On Thu, 25 Mar 2021 at 10:00, Suresh Anaparti <
> > suresh.anapa...@shapeblue.com>
> > wrote:
> >
> > > Hi all,
> > >
> > > The default git branch name 'master' was replaced with 'main' on
> > GitHub
> > > [2][3] and in the wider Git community [4]. For those that have
> > missed the
> > > broader discussion in society, the term 'master' is offensive to
> some
> > > people [1]. This is widely considered insensitive if not illegal,
> > hence the
> > > proposed change.
> > >
> > > It seems fitting the CloudStack would follow this example of
> > > inclusiveness. For this, the project would rename its default
> branch
> > name
> > > of all the repositories to 'main'. In addition, all the applicable
> > > integration points (Eg: Travis-CI, etc) using these repositories
> > have to
> > > replace the branch name 'master' with 'main'.
> > >
> > > The sample steps to rename and replace the default branch to 'main'
> > are
> > > here:
> > >
> >
> https://faun.pub/git-step-by-step-renaming-a-master-branch-to-main-16390ca7577b
> > >
> > > I would like to hear your thoughts and suggestions on this.
> > >
> > >
> > > [1]
> > >
> >
> https://www.theserverside.com/feature/Why-GitHub-renamed-its-master-branch-to-main
> > &g

Congratulations to Sven - Apache Software Foundation Member

[Paul Angus]

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

 

Congratulations to Gabriel - CloudStack PMC Chair

[Paul Angus]

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

 

Basic network CANNOT be deprecated as CloudStack is right now.

[Paul Angus]

Hi all,

I was doing some testing recently and found that the premise used to depreciate 
'basic networking' is completely wrong.

Guest networks in basic networking, have ONE SUBNET PER POD, and a gateway per 
pod for inter-pod guest traffic.   Advanced networks with security groups' 
guest networking has ONE SUBNET per VLAN, which spans the ENTIRE ZONE.

They may look very similar when there is only one cluster.
BUT THEY ARE COMPLETELY DIFFERENT.

I'm all for renaming the network styles (basic and advanced is just 
meaningless).  But an 'advanced network with security groups' with one network 
is nothing like a basic networking zone.


Kind regards

Paul Angus

RE: [DISCUSS]/[PROPOSAL] draft PRs

[Paul Angus]

+1

I've also created a script that trawls our PRs to both label and create a 
report.  Right now it uses the Draft 'type' to figure out what's 'coming soon'.
Ps. Once polished I plan to contribute the docker containers that takes away 
all 'environment creation' hassles.


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


-Original Message-
From: Abhishek Kumar  
Sent: 17 February 2020 11:09
To: Daan Hoogland ; dev 
Subject: Re: [DISCUSS]/[PROPOSAL] draft PRs

+1

From: Daan Hoogland 
Sent: 14 February 2020 17:33
To: dev 
Subject: [DISCUSS]/[PROPOSAL] draft PRs

devs, I thought I had already sent a mail about this but i cannot find it.
I'm sure i had mentioned it somewhere (probably on github).
this is a follow up on [1] and hopefully you'll agree, a slight improvement.

here it comes:

At the moment we are creating PRs with a [WIP] or [DO NOT MERGE] tag in the 
title. This title stands the chance of being merged once we agree the PR is 
ready for merge. It also clutters the title.

Github has introduced a nice feature a while ago; draft PR. When creating a PR 
you can opt not to open it for merge but as draft. Choose a button left of the 
"Create pull request" button, marked "Create draft PR". It will be a full PR 
with all CI and discussion possibilities open. The only difference is the merge 
button being disabled. One will than have to make/mark it "ready for merge" 
before it *can* be merged.

[1]
https://lists.apache.org/thread.html/f3f0988907f85bfc2cfcb0fbcde831037f9b1cb017e94bc68932%40%3Cdev.cloudstack.apache.org%3E
please shoot any comments you may have back at me, thanks

--
Daan

abhishek.ku...@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

[Paul Angus]

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

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

RE: New Joiner

[Paul Angus]

Hi Hoang,

Welcome to the CloudStack community. Glad to have you aboard!

A small point of order, there is no CloudStack Primate project, only the 
CloudStack project.  In fact, what was known as Primate, this is now just 
CloudStack's UI, an integral part of CloudStack.  We are very keen to keep 
CloudStack as a 'turnkey' solution, where a user wouldn't have to do install 
multiple CloudStack 'products' in order to use CloudStack.

That said, any contribution to any part of CloudStack, is extremely welcome. 
Thank you.

Kind regards,


Paul


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


-Original Message-
From: Unitech Mai Nguyen  
Sent: 04 November 2020 02:32
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.

[ANNOUNCE] Code freeze for 4.15

[Paul Angus]

Hi fellow CloudStackateers,



I'd like to announce a feature code for CloudStack and CloudStack Primate.

We'll go through a period testing  (and only bug fix merges) to get us to
an RC state for both. Then vote on both at the same time (more or less).



Could I ask everyone to have a look at open PRs and issues and help out
with reviews and fixes.



The new UI (Primate) goes GA with this release.  It was a huge endeavour,
so the odd niggle is to be expected,  so please remember to conduct your
manual testing using the new UI and report any bugs.


Many thanks


Paul Angus

[ANNOUNCE} 4.15 Code Freeze

[Paul Angus]

Hi Everyone,

I hope that you are all coping with the weird world that we are in at the
moment.  And my best wishes to anyone and everyone and hope that we can all
get together at a collab again soon.

I emailed a few months ago to make sure that there were no problems with
having a code freeze in preparation for a new release.  So I'd like to
follow up to say that I'd like to put the code freeze in place at the *end
of next week*, and start the process of ensuring that the master branch is
stable.

I'd like to request that everyone start giving a thought to testing too.
There is a major vSphere refactor to enable a lot of new features which will
need as many scenarios at it as we can, and also we promised the world a GA
Primate.  I understand that there are very few (if any) open bugs for
Primate, but let's try to make sure that we've covered as much as possible.

So, the summary
---

- Code freeze at the end of next week.

- Get ready for testing, and when testing please only use Primate.


Many thanks

Paul Angus

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

[Paul Angus]

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

RE: [PROPOSE] Code freeze for 4.15

[Paul Angus]

Hi 吕海蛟,

Are you saying that you have a feature that you have developed and have a PR 
for, a feature that there is a PR existing for that you would like merging, or 
a feature request for _someone_ to develop?


From: 吕海蛟 
Sent: 21 September 2020 04:49
To: dev@cloudstack.apache.org
Subject: Re: [PROPOSE] Code freeze for 4.15

Sounds good.

Can we have a new feature,  #4141 Load balancer customization in 4.15 ?  We 
would love to test this feature in our projects.

Thanks!


[cid:image001.jpg@01D6900D.329C0A70]  云上云下，IT简化
--
吕海蛟
Product Engineering & Innovation Center (PEIC)
北京华胜锐盈科技有限公司

上海普陀区大渡河路168弄26号北岸长风K栋606室
邮编：200062
Office: +86-21-62351222
Mobile: +86-18602198181



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

RE: Triage Permission

[Paul Angus]

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
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
> 3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK 
> @shapeblue
>
>
>
>

--
Daan

[PROPOSE] Code freeze for 4.15

[Paul Angus]

Hi all,

 

Its around that time of year again.  We owe the world a GA version of
Primate + there is support for Ubuntu 20.04, CentOS 8 and XenServer/XCP-ng
8, a massive update to the vSphere capabilities and many fixes..

 

So, I'd like to propose a feature freeze in two or three weeks' time
(depending how everyone else is looking with any features).  For people who
are a still way out with anything that they're working on; I'd hope to get
back on track with the next release *early* in the new year.

 

Unless there are any objections, I'll go ahead with getting a freeze date
out sooner rather than later.

 

Kind regards

 

 

Paul Angus

 

RE: [DISCUSS] Management server default port conflict

[Paul Angus]

I like Wei's idea - fast fail with explanation is usually best.

Re ports in general... You can register ports with IANA, but IANA has a number 
of ports where it has allowed more that one protocol to register the same port 
number, so they don't seem to follow their own rules either.



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


-Original Message-
From: Wei ZHOU  
Sent: 02 July 2020 07:44
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Management server default port conflict

Agree with Ron.

Besides the change in cloudstack documents, it would be nice to check all 
cloudstack ports (8080, 8250, 9090, 8096/integration, 9595/prometheus) and 
display error messages before starting java thread when start service 
cloudstack-management. It helps users to find the root cause and stop services 
to free the ports.

-Wei

On Thu, 2 Jul 2020 at 04:42, Ron Wheeler 
 wrote:

> Is there any hope of getting projects to follow the rules?
>
> One would think that Cloudstack developers would be the most likely to 
> understand networking, the Internet and system administration.
>
> Ron
>
> On 2020-07-01 12:53 p.m., Andrija Panic wrote:
> > (true that, Ron...)
> >
> > On Wed, 1 Jul 2020, 15:27 Ron Wheeler, 
> >  wrote:
> >
> >> If the open source community just got their act together and 
> >> registered their ports and stopped using ports registered to other 
> >> projects, this would not happen.
> >>
> >> There is no shortage of available ports, there is just a complete 
> >> lack of professionalism in the community and it causes unnecessary 
> >> headaches for users.
> >>
> >> Stop using ports registered to other projects.
> >> Register the ports for Cloudstack and encourage/insist that others 
> >> do so as well.
> >> Publicly shame projects and products that use ports that they have 
> >> not registered.
> >> To set a good example, in documentation and examples stop using 
> >> ports in the registered range for applications that should use 
> >> ports in the private/dynamic range.
> >>
> >>
> >> Ron
> >>
> >>
> >> On 2020-07-01 7:36 a.m., Abhishek Kumar wrote:
> >>> +1 with adding documentation.
> >>>
> >>> And maybe we should also refactor the port check logic and error
> >> message. Currently, code just tries to connect the socket for the 
> >> port
> and
> >> if it fails that with the message,
> >>> Detected that another management node with the same IP XX.XX.XX.XX 
> >>> is
> >> already running, please check your cluster configuration
> >>> Instead of the cockpit, it can be any other service/process. 
> >>> Should we
> >> try to get details of that service in the logs, exception message 
> >> so the user can make changes?
> >>> Regards,
> >>> Abhishek
> >>> 
> >>> From: Rohit Yadav 
> >>> Sent: 01 July 2020 13:04
> >>> To: dev@cloudstack.apache.org ;
> >> us...@cloudstack.apache.org 
> >>> Subject: Re: [DISCUSS] Management server default port conflict
> >>>
> >>> I think we can document in our CloudStack qig/release/install 
> >>> notes to
> >> say users must disable cockpit on CentOS8. Here are my 2paisas;
> >>> *   Most users using CentOS (7/8) won't use a single-host specific
> >> management tool/UI such as cockpit; they would probably use some 
> >> fleet management software or automate using ansible/puppet/ceph etc.
> >>> *   Last time I checked the minimal CentOS-8 ISO does not install
> >> cockpit or that it is enabled by default (service does not run by
> default
> >> until you active the port 9090 target)
> >>> *   Some users may have monitoring scripts/tools or security rules
> >> that expect port 9090 to be used by CloudStack, so it's probably 
> >> safer
> to
> >> ask users to change port for cockpit than CloudStack by default
> >>> Regards.
> >>>
> >>> 
> >>> From: Abhishek Kumar 
> >>> Sent: Wednesday, July 1, 2020 11:14
> >>> To: dev@cloudstack.apache.org ;
> >> us...@cloudstack.apache.org 
> >>> Subject: [DISCUSS] Management server default port conflict
> >>>
> >>> Hi all,
> >>>
> >>> I would like to know everyone's opinion regarding an issue seen 
> >>> with
> >> CloudStack on CentOS8 (https://github.com/apache/cloudstack/pull/4068).
> >> CentOS8 comes with cockpit (https://cockpit-project.org/) installed
> which
> >> uses port 9090, although it is not active by default. CloudStack
> management
> >> server also needs port 9090. And when CloudStack management server 
> >> is started with systemd it triggers the start of cockpit first and
> management
> >> server fails to start,
> >>>
> >>> 2020-06-25 07:20:51,707 ERROR [c.c.c.ClusterManagerImpl] 
> >>> (main:null)
> >> (logid:) Detected that another management node with the same IP
> 10.10.2.167
> >> is already running, please check your cluster configuration
> >>> 2020-06-25 07:20:51,708 ERROR 
> >>> [o.a.c.s.l.CloudStackExtendedLifeCycle]
> >> (main:null) (logid:) Failed 

RE: Managed Storage and HA

[Paul Angus]

dReads": 890959,
> "unalignedWrites": 358758,
> "volumeAccessGroups": [
> 1
> ],
> "volumeID": 2,
> "volumeSize": 2147483648000,
> "volumeUtilization": 0,
> "writeBytes": 8957684071424,
> "writeBytesLastSample": 0,
> "writeLatencyUSec": 0,
> "writeLatencyUSecTotal": 16780712096,
> "writeOps": 406101472,
> "writeOpsLastSample": 0,
> "zeroBlocks": 495471346
> }
> ]
> }
> }
>
> On 6/2/20, 9:11 AM, "Sven Vogel"  wrote:
>
> NetApp Security WARNING: This is an external email. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
>
>
>
>
> Hi Paul,
>
> Thanks for the answer and help.
>
> Ok. Secondary Storage is no good solution what I understand.
>
> > 1. HAManager
> > 2. HighAvailbilityManager
> > 3. KVMHAConfig
>
>
> which of the three should we expand and which one should be active?
>
> @Mike did you know somethings like that if there is a check of 
> volume activity?
> Maybe we can poll the API but I think this will be a massive 
> polling
> (overload) if we poll for each volume.
> Ah the moment I don’t have any idea how this could work.
>
> Cheers
>
> Sven
>
>
> __
>
> 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
>
> Geschäftsführer:
> Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
> Registergericht: Leipzig HRB 9065
>
> Zertifiziert nach:
> ISO/IEC 27001:2013
> DIN EN ISO 9001:2015
> DIN ISO/IEC 2-1:2011
>
> 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.
> > Am 01.06.2020 um 19:30 schrieb Paul Angus 
>  >:
> >
> > Hi Sven,
> >
> > I think that there is a piece of the jigsaw that you are missing.
> >
> > Given that the only thing that we know, is that we can no longer 
> communicate with the host agent;  To avoid split brain/corruption of 
> VMs, CloudStack must determine if the guests VMs are still running on 
> the host not.  The only way we can do that is look for disk activity 
> created by those VMs.
> >
> > Using a secondary storage heartbeat would give a false 'host is 
> down' if say a switch went down carrying sec storage and mgmt. traffic
> >
> > Wrt solidfire, you could poll SolidFire via API for activity on 
> the volumes which belong to the VMs on the unresponsive host.  I don't 
> know if there is an equivalent for Ceph.
> >
> > Kind regards
> >
> >
> > Paul Angus
> >
> >
> >
> > paul.an...@shapeblue.com
> > www.shapeblue.com
> > 3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
> > @shapeblue
> >
> >
> >
> >
> > -Original Message-
> > From: Sven Vogel 
> > Sent: 01 June 2020 12:30
> > To: dev 
> > Subject: Managed Storage and HA
> >
> > Hi Community,
> >
> > I try to encounter how HA works. Our goal is it to make it 
> usable with managed storage like (

RE: [DISCUSS] New default template

[Paul Angus]

My 2 cents:

The default template is not there for general or even production use, it’s 
there for people to 'kick the tires' and either see if CloudStack is what they 
want or check that their installation is generally OK.

Therefore (IMO) the pre-requisites are:

- small download size
- compatibility across all of our supported hypervisors
- compatibility with all CloudStack features; i.e. live memory and CPU 
addition, hot disk-pluging, live migrations which require hypervisor tools 
installed, passing of user-data, meta-data, ssh keys and password resets to the 
VM via VR and config-drive.
- OS commands that users will be relatively familiar with.
- ability to be leverage by Marvin tests to perform smoke and integration tests

You know - the usual stuff...

So that we know that the template should 'always work', I don't think that we 
should point to an upstream repo, but take an OS version, add/configure 
whatever is strictly required to meet our requirements, and keep in the 
CloudStack downloads.

Ok, so more like $10 ..

Kind regards

Paul Angus


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


-Original Message-
From: Andrija Panic  
Sent: 03 June 2020 13:03
To: users 
Cc: dev ; Abhishek Kumar 

Subject: Re: [DISCUSS] New default template

Whatever is a choosen as the new one, needs to be compatible with ALL the 
current hypervisor we support (i. e. VMware 6.0 and up, XenServer 7.0 and up 
and KVM of various flavours).
So that needs to be taken into consideration when speaking about exotic OS-es 
or even the newest ones (Ubuntu 20/CentOS 8) to find a proper OS mappings on 
hypervisor side that will allow it to run normally.



On Wed, 3 Jun 2020, 12:21 ,  wrote:

> Hi,
>
> I'd like to restate my previous stance on this which is - if not to 
> have a proper "market place" of trusted and tested templates - at 
> least to cover the popular ones.
> The basics imho would be CentOS and Ubuntu, with this we cover 99% of 
> the user requirements.
> I'd propose to go with the latest and greatest of both, Ubuntu 20.04 
> and
> CentOS8 respectively (supported 2029).
> I can repurpose the current build machine for openvm.eu and "donate" 
> it to the project so it's not a "third party" any more.
>
> my 2 pence
>
> On 2020-06-03 08:58, Abhishek Kumar wrote:
> > Hi all,
> >
> > I would like to hear everyone's opinion on a new default template in 
> > CloudStack.
> > Currently, we are using CentOS 5.x for different hypervisors but it 
> > is quite old(already completed its support life) and either the 
> > support for it has been removed
> > (https://github.com/xcp-ng/xcp/wiki/Guest-System-Support) or in 
> > legacy (
> https://www.vmware.com/resources/compatibility/search.php?deviceCatego
> ry=software=1=272=448=1_interval
> =10=Partner=Asc=16
> )
> > in different hypervisors.
> > Therefore, I think it is time now to move to a newer OS template. In 
> > my understanding CentOS7 is the minimum viable choice if we are 
> > continuing with CentOS. This can be the preferred choice as we 
> > already have tested templates for it on different hypervisors and it 
> > has 4 years left in its cycle.
> >
> > We can also explore Ubuntu’s cloud-images of 20.04. And if we want 
> > to go with something very light-weight we can think about something 
> > like Alpine Linux.
> >
> > Please have your say. Also, do you think this can be included in 
> > 4.15 itself so we can have a proper default template for something 
> > like XCP-ng 8.x which doesn't support CentOS 5 (and PV VMs)?
> >
> > Regards,
> > Abhishek
> >
> >
> > abhishek.ku...@shapeblue.com
> > www.shapeblue.com
> > 3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK 
> > @shapeblue
>

RE: Managed Storage and HA

[Paul Angus]

Hi Sven,

I think that there is a piece of the jigsaw that you are missing.

Given that the only thing that we know, is that we can no longer communicate 
with the host agent;  To avoid split brain/corruption of VMs, CloudStack must 
determine if the guests VMs are still running on the host not.  The only way we 
can do that is look for disk activity created by those VMs.

Using a secondary storage heartbeat would give a false 'host is down' if say a 
switch went down carrying sec storage and mgmt. traffic

Wrt solidfire, you could poll SolidFire via API for activity on the volumes 
which belong to the VMs on the unresponsive host.  I don't know if there is an 
equivalent for Ceph.

Kind regards


Paul Angus



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


-Original Message-
From: Sven Vogel  
Sent: 01 June 2020 12:30
To: dev 
Subject: Managed Storage and HA

Hi Community,

I try to encounter how HA works. Our goal is it to make it usable with managed 
storage like (Netapp Solidfire / maybe it works with CEPH too) so if its 
possible.

This is a good guide and for some times we fixed and added the missing keys.
https://cwiki.apache.org/confluence/display/CLOUDSTACK/High+Availability+Developer%27s+Guide<https://cwiki.apache.org/confluence/display/CLOUDSTACK/High+Availability+Developer's+Guide>
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Host+HA

In the database I found out there are three different types of HA.

If you select in the configuration table "SELECT * FROM `configuration` WHERE 
`component` LIKE '%ha%' LIMIT 0,1000;“ you will get three types of components.

1. HAManager
2. HighAvailbilityManager
3. KVMHAConfig

"HAManager and HighAvailbilityManager" are the base which was extended from 
Rohit with „KVMHAConfig“ - KVM with stonith fencing.

I understand all things work together but maybe I need to understand the 
process a little bit better.


To clarify I write down what I think to each of them. This is what I understand 
but please correct me or help me to understand it a little bit better.

—>I found out that if we use managed storage a restart of virtual machines only 
works on the same host. This is what I understand the lack of the missing 
heartbeat file on the shared storage because we don’t have shared storage like 
NFS.

—
"If the network ping investigation returns that it cannot detect the status of 
the host, CloudStack HA then relies on the hypervisor specific investigation. 
For VMware, there is no such investigation as the hypervisor host handles its 
own HA. For XenServer and KVM, CloudStack HA deploys a monitoring script that 
writes the current timestamp on to a heartbeat file on shared storage."
—

And

—
For the initial release, only KVM with NFS storage will be supported. However, 
the storage check component will be implemented in a modular fashion allowing 
for checks using other storage platforms(e.g. Ceph) in the future.
—


We would implement a plugin or extend this for managed storage but at the 
moment I need to understand where this should happen. Since managed storage 
uses different volumes for each VM we should its not easy to make an storage 
heartbeat like NFS. the lack of one missing volume don’t means the hole storage 
has an problem so I think its not easy to encounter from one volumes to a 
complete storage.

We don’t use KVMHAConfig a the moment and encounter that if a Host goes down 
(offline) the virtual machines will not be restarted on another host. They will 
only restarted on the host if the host comes back.(online). We don’t want a 
hard fencing of the hosts but we want a correct determination whether the host 
is still alive. Fencing would maybe in our case a little bit hard because we 
don’t have an hard data corruption on entire storage.

Some questions.
1. let's assume correctly that the HA don’t work without an shared storage and 
network ping? Is this the cause why our virtual machines will not restarted on 
another host? Is this correct or do we have an config problem?
2. Where could the plugin be implemented? Is there a preferred place?
3. If point 1. Is correctly I thought the idea would be to add an global flag 
to use the secondary storage (NFS) as heartbeat to find out if there is any 
host inactive?

Thanks and Cheers

Sven


__

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

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

RE: [ Proposal ] Managing CloudStack Load Balancer configuration

[Paul Angus]

This looks great @Wei Zhou do you have a timeline for when you think a PR will 
appear?

As probably a discussion thread for after this is in, do we think that there is 
mileage in allowing a user to upload their own haproxy config? There would have 
to be a binary 'cloudstack controlled config file' vs 'user controlled config 
file' switch somewhere, but then power users could tinker all they liked with 
the haproxy config, and CloudStack can stick to orchestrating relatively simple 
configurations ??

Kind regards


Paul.



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


-Original Message-
From: Wei ZHOU  
Sent: 06 May 2020 08:38
To: dev@cloudstack.apache.org
Subject: Re: [ Proposal ] Managing CloudStack Load Balancer configuration

cool, Thanks Liridon and Gregor.
We will take them into consideration.

-Wei


On Tue, 5 May 2020 at 15:12, Ismaili, Liridon (SWISS TXT) < 
liridon.isma...@swisstxt.ch> wrote:

> Hi Wei,
>
> That's some great improvements to the HAProxy! We couldn't realize 
> some projects because of the missing features on the HAProxy therefore 
> we are happy to hear that there will be some improvements.
> As an addition to the proposal of you we would like to see the 
> possibility to separate timeout settings (client/server/connect/...) 
> as these timeout can be different.
> We would also like to have the timeout settings available under the 
> LoadbalancerRule
>
> as a summary:
> - Separate options for all timeout parameters 
> (client/server/connect/...)
> - Timeouts also per LoadbalancerRule, not only Network
>
> We also thought about some "nice to have" additions:
> - check customization: HTTP Check, Check Interval, etc.
> - LoadbalancerRule: Custom Server string & Custom Listen string (only 
> Domain Admin)
> - Network: Custom Defaults (only Domain Admin)
>
> Please let me know what you think about these additions.
>
> Best Regards
> Liridon
>
> -Original Message-
> From: "Riepl, Gregor (SWISS TXT)"  %22Riepl,%20Gregor%20%28SWISS%20TXT%29%22%20%3cGregor.Riepl@swisstxt.c
> h
> %3e>>
> Reply-To: dev@cloudstack.apache.org
> To: dev@cloudstack.apache.org  22...@cloudstack.apache.org%22%20%3c...@cloudstack.apache.org%3e>>
> Subject: Re: [ Proposal ] Managing CloudStack Load Balancer 
> configuration
> Date: Mon, 04 May 2020 10:22:39 +
>
>
> Hi Wei,
>
>
> Thank you for this proposal!
>
> We are also very much interested in this feature.
>
>
> There's a few things we're not quite happy with, though - but we still 
> need to discuss this internally a bit.
>
> Liridon or myself will give some feedback soon.
>
>
> Regards,
>
> Gregor
>
> 
>
> From: Wei ZHOU <
>
> 
>
> ustcweiz...@gmail.com
>
> >
>
> Sent: 01 May 2020 08:01
>
> To:
>
> 
>
> dev@cloudstack.apache.org
>
>  <
>
> 
>
> dev@cloudstack.apache.org
>
> >
>
> Subject: [ Proposal ] Managing CloudStack Load Balancer configuration
>
>
> Our improvements to cloudstack load balancer (implemented by HAproxy 
> in the
>
> VRs) allow cloudstack users to manage certain restricted configuration
>
> settings. With this feature, users can
>
>
> * Change basic configuration of HAproxy (e.g. set the amount of 
> allowed
>
> connections),
>
>
> * choose if load balancer is transparent,
>
>
> * enable or disable the support for SSL offloading in isolated networks.
>
>
> * choose if load balancer supports HTTP/2.
>
>
> * more settings.
>
>
>
>
> To make this possible to the user, we provide two forms on cloudstack 
> GUI
>
> (old GUI, will add changes on Primate) from which the settings can be
>
> managed and applied in virtual routers.
>
>
>
>
> FS can be found at
>
> <
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VR+haproxy+cust
> omization+in+CloudStack
> >
>
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VR+haproxy+cust
> omization+in+CloudStack
>
>
>
>
> Any suggestions ?
>
>
>
>
> Kind regards,
>
>
> *Wei Zhou*
>
>
> Principal Cloud Engineer
>
>
> Leaseweb Global B.V.
>

RE: [DISCUSS] Primate - publishing release and docs

[Paul Angus]

With a bit of - TL;DR ...
And as per Rohit's scope, I'm hand-waving over the formal release process and 
cycle for now.

From our by-laws [1], Non-technical decisions don’t require a vote (I don’t 
agree the rule, but it is what it is); so as no one has disagreed with the idea 
of skipping an RC vote for a tech preview of Primate, I think that’s we can go 
ahead with that unless someone does pop up with an objection.

I would suggest that we don't have call iterations of the tech preview 'RCs'. 
The tech preview is not a 'Release', as that _would_ require a vote, so to have 
release candidates would confuse the issue.  

Wrt documentation, as this is a tech preview, I think that we should limit 
ourselves to the bare minimum to get Primate up and running.  The project has a 
readme for those looking to develop Primate already.  
I think that we need a BIG disclaimer/health warning at the start, instructions 
to download and 'install' and we can trawl github for open issues to give a 
'point-in-time' list of known issues (similar to what we do for PRs in the 
CloudStack releases).  

My 10c would be to simply:  agree when the preview is ready, build the static 
pages, create a tarball and put that on downloads.cloudstack.org .
The instructions are then download, unpack, and place in 
/usr/share/cloudstack-management/webapp/Primate ...

...super simple.

Regards


Paul.



[1] http://cloudstack.apache.org/bylaws.html section 3.4.2

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


-Original Message-
From: Sven Vogel  
Sent: 11 May 2020 10:04
To: us...@cloudstack.apache.org
Cc: dev 
Subject: Re: [DISCUSS] Primate - publishing release and docs

Hi Rohit, Hi Daan,

 1.  Documentation for tech preview

I agree with Rohit. For me the both suggestions with links sound like a good 
idea. We should add the download links for official releases or installations 
for each method on both sites. Maybe its a good idea to have both in sync to we 
save us the double work. How can we get them in sync? An important point is 
always the double work. So if there is a method to get them fast in sync in see 
no problem but if there is many hand work to do maybe its easier to refer from 
wiki -> to readthedocs or vice versa. I would like to prevent outdated docs on 
one place.

@Daan
I think Primate should be documented by means of help pop-ups with links to the 
underlaying API and admin docs. How big do you expect this documentation to 
become? (I would think it is only a short readme on first
use)

— How could this work? Where we could find the help pop-ups and where should 
they located?



 2.  Types of Primate packages:

*   deb/rpm: Primate already supports deb/rpm packages. This mode will allow 
users to install "cloudstack-primate" on the management server where Primate 
will be served from the management server just like the old UI.
*   docker container: Primate support docker containers to be built/used which 
takes a nginx config to proxy /client path to any management server.
*   archive build: A built archive (tar.gz) of Primate can be extracted and 
allow users/admins to do any custom hosting with it, other than (a) or (b).

— For me all three methods are a good idea because we give the user the 
greatest flexibility.

a) a repository for rpm and deb
b) publish a docker like ready to use version always dockerhub. By the way 
everybody can build there own docker container

c) publish the tar.gz on the release section in GitHub or as tar.gz on 
repository too? What do you think @Rohit, @Daan?



 3.  Hosting packages/releases

*   Use download.cloudstack.org for hosting (a) 
deb/rpm repos, and (c) archive builds.

— sounds good to me. I would prefer this place.

*   Use the apache dockerhub org to publish official Primate container images: 
https://hub.docker.com/r/apache/cloudstack-primate

— sounds good to me. I would prefer docker hub

My suggestion is to host the tar.gz as release with tags on GitHub, but I am 
open to put it on the repsository too. Its depend on the work we have and maybe 
its better to have rpm, deb or

So I thinks this is good because we have three good understandable places. Most 
people look for a repository for rpm/deb, docker on dockerhub and code release 
(tar.gz) on GitHub.

RE: Start problem with Marvin

[Paul Angus]

Hi Dirk,

Sorry that no one has been able to get back to you yet, a lot of people are 
‘off’ at the moment.

The place to look at the cause of this would be the management server logs.  
They would give the specific reason that the hosts could not be added.
If you can’t figure it out from the logs, put them in pastebin (or similar) and 
let us know. (attachments are stripped in the mailing list).

Kind regards

Paul Angus


From: Klahre, Dirk 
Sent: 14 April 2020 10:03
To: dev@cloudstack.apache.org
Subject: Start problem with Marvin

Hi All,

my name is Dirk and I'm the new developer for cloudstack at the Itelligence GMS.
I have been working at Itelli since 2015 and look forward to a good 
cooperation. ☺

I hope this is the correct channel to ask development questions.


My first step was to build my development environment and I used your dev docs 
for that.
So far it has worked well, but now I have a problem with the cmd "marvincli 
deploydc config-file=marvin_config.cfg".

My configuration is follow

OS: Windows
IDE:Apache Netbeans (works directly in windows)

- MySQL and Marvin is encapsulated together in a docker container
- MySQL and Docker is included in Netbeans and works correctly.
- Build, Deployment, Debug of Cloudstack and connection to Mysql works also 
well.
- I use Cloudstack version 4.13
- For Python and similar stuff I using WSL as cli

Also follow cmds finished successfully
 mvn -Pdeveloper -Dsimulator -DskipTests clean install
 mvn -Pdeveloper -pl developer -Ddeploydb
 mvn -Pdeveloper -pl developer -Ddeploydb-simulator

After this I started the jetty server with follow cmd successfully
  mvn -pl client jetty:run -Dsimulator 
-Dorg.eclipse.jetty.annotations.maxWait=120

Now if I execute marvin cmd in the docker container I get following error at 
addHost method

Exception Occurred :['Traceback (most recent call last):\n', '  File 
"marvin/marvin/deployDataCenter.py", line 146, in addHosts\nret = 
self.__apiClient.addHost(hostcmd)\n', '  File 
"/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
 line 2418, in addHost\nresponse = self.connection.marvinRequest(command, 
response_type=response, method=method)\n', '  File 
"/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line 
379, in marvinRequest\nraise e\n', 'CloudstackAPIException: Execute cmd: 
addhost failed, due to: errorCode: 530, errorText:Unable to add the host\n']
Exception Occurred :['Traceback (most recent call last):\n', '  File 
"marvin/marvin/deployDataCenter.py", line 146, in addHosts\nret = 
self.__apiClient.addHost(hostcmd)\n', '  File 
"/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
 line 2418, in addHost\nresponse = self.connection.marvinRequest(command, 
response_type=response, method=method)\n', '  File 
"/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line 
379, in marvinRequest\nraise e\n', 'CloudstackAPIException: Execute cmd: 
addhost failed, due to: errorCode: 530, errorText:Unable to add the host\n']
Exception Occurred :['Traceback (most recent call last):\n', '  File 
"marvin/marvin/deployDataCenter.py", line 146, in addHosts\nret = 
self.__apiClient.addHost(hostcmd)\n', '  File 
"/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
 line 2418, in addHost\nresponse = self.connection.marvinRequest(command, 
response_type=response, method=method)\n', '  File 
"/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line 
379, in marvinRequest\nraise e\n', 'CloudstackAPIException: Execute cmd: 
addhost failed, due to: errorCode: 530, errorText:Unable to add the host\n']
Exception Occurred :['Traceback (most recent call last):\n', '  File 
"marvin/marvin/deployDataCenter.py", line 146, in addHosts\nret = 
self.__apiClient.addHost(hostcmd)\n', '  File 
"/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
 line 2418, in addHost\nresponse = self.connection.marvinRequest(command, 
response_type=response, method=method)\n', '  File 
"/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line 
379, in marvinRequest\nraise e\n', 'CloudstackAPIException: Execute cmd: 
addhost failed, due to: errorCode: 530, errorText:Unable to add the host\n']
Exception Occurred :['Traceback (most recent call last):\n', '  File 
"marvin/marvin/deployDataCenter.py", line 146, in addHosts\nret = 
self.__apiClient.addHost(hostcmd)\n', '  File 
"/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
 line 2418, in addHost\nresponse = self.connection.marvinRequest(command, 
response_type=response, method=method)\n', '  File 
"/usr/local/lib/pytho

RE: Introduction

[Paul Angus]

Welcome back to Apache CloudStack!!

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


-Original Message-
From: Suresh Kumar Anaparti  
Sent: 14 April 2020 10:27
To: dev 
Subject: Introduction

Hi All,

This is Suresh (Suresh Kumar Anaparti), have recently joined ShapeBlue. I’m 
happy to rejoin and continue my contribution to the community. Looking forward 
to work with you all.

Regards,
Suresh

Release packaging noredist

[Paul Angus]

Hi All,

This seems a good point to revisit our no-redist vs oss builds - the fact that 
we have them seems to cause the occasional painful experience for users (mostly 
VMware vSphere ones).


As far as I'm aware, the old NetApp code has been removed so there is no need 
for ontap jars, the vSphere webclient sdk jar [1] is now available under the 
MIT license [2], so there is no need for that to be considered 'no-redist'.

According to our own install-non-oss.sh, the netscaler jar is no longer 
required.

That just leaves the F5 jars.   Does anyone know if the F5 support in 
CloudStack is still working?

[1] 
https://github.com/vmware/vsphere-automation-sdk-java/blob/master/lib/vim25.jar
[2] https://github.com/vmware/vsphere-automation-sdk-java/blob/master/LICENSE



Regards

Paul

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

RE: Automate CloudStack release packaging with Jenkins

[Paul Angus]

Awesome, thanks Gabriel!

If you need any help just shout, I think a few 'stackers have experience 
setting up Jenkins to package the code.

Regards

Paul.


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


-Original Message-
From: Gabriel Beims Bräscher  
Sent: 06 April 2020 12:56
To: Sven Vogel 
Cc: dev@cloudstack.apache.org
Subject: Re: Automate CloudStack release packaging with Jenkins

Hello all,

Considering that there are no objections, I will spin a Jenkins node this week 
:)

Cheers,
Gabriel.

Em sáb., 4 de abr. de 2020 às 18:21, Sven Vogel 
escreveu:

> I am aboard and can help. first with configuring. +1 from me. We use 
> Jenkins too and read from Pierre he has maybe an old config. since 
> corona I don’t got our test environment running in data Center :( .. 
> If this will better I can share Jenkins slaves.
>
> Cheers
>
>
> __
>
> 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
>
> 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
>
> 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.
> > Am 27.03.2020 um 17:07 schrieb Daan Hoogland :
> >
> > I'd love it to have a nightly @Gabriel Beims Bräscher <
> gabrasc...@gmail.com>
> > and in general i like the idea. Maybe (running in front of myself 
> > here)
> it
> > can have a build from custom commitish?
> > anyway :+1:
> >
> >> On Fri, Mar 27, 2020 at 12:46 PM Gabriel Beims Bräscher < 
> >> gabrasc...@gmail.com> wrote:
> >>
> >> Hello @dev,
> >>
> >> Since release 4.12.0.0 I have been helping with the process of 
> >> making packages available at https://download.cloudstack.org. Such 
> >> a process takes time and demands someone to build the packages 
> >> "manually".
> >>
> >> The idea is to enhance it to a point that the RM in a future 
> >> release can press a button and the packages will be "automagically" 
> >> generated and
> made
> >> available at the mirrors.
> >>
> >> With that in mind, I would like to propose the addition of a 
> >> Jenkins
> server
> >> to help with the packaging process. PCextreme would be happy to 
> >> donate
> and
> >> configure a Jenkins master and a few slaves for doing that. Anyone 
> >> interested in donating Jenkins slaves would be welcome as well.
> >>
> >> The plan is to let Jenkins (e.g. https://jenkins.cloudstack.org ?) 
> >> open for any committer/PMC primarily as a tool for building 
> >> packages during the release process. Such Jenkins could serve for 
> >> multiple automation
> purposes
> >> but at first, the goal is to have a "release-packages" job for
> generating
> >> "VOTE" and release packages. Additionally, a set of people (e.g. 
> >> active PMCs and release managers) would have root access to the VM 
> >> to manage inside scripts, install dependency packages, and run 
> >> updates when necessary.
> >>
> >> Please let me know if that proposal suits the project needs.
> >> In case we have no objections I will start working on it.
> >>
> >> Best Regards,
> >> Gabriel.
> >>
> >
> >
> > --
> > Daan
>

[ANNOUNCE] Next PMC Chair & VP Apache CloudStack Project - Sven Vogel

[Paul Angus]

Hi Everyone,

It gives me great pleasure to announce that ASF board last night
accepted our PMC's nomination of Sven Vogel as the next VP of the
project.

As I hand over the reins, I would like to thank everyone for the
support I've received over the past year. It looks like being a very
difficult year ahead for the world in general, and I wish everyone
good luck in navigating it and urge everyone to try to show patience
and compassion in these trying times.

I'd like to thank Sven for volunteering for the post and wish him the
best of luck, I'm sure that he'll do a great job.

So please join me in welcoming Sven Vogel as the new Apache CloudStack
VP and PMC Chair !

RE: mysql-connector-python

[Paul Angus]

I’ve gotten to the bottom of my query, it was the Java 11 jar dependency that 
Rohit baked-in rather than the python related jars.


From: Andrija Panic 
Sent: 17 March 2020 18:54
To: dev 
Cc: Paul Angus ; Andrija Panic 

Subject: Re: mysql-connector-python

I *believe* that the explicit need for python-dns came with the newest version 
of mysql-connector-python (the "broken one") - the explicit need for it was not 
there before


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

On Tue, 17 Mar 2020 at 11:58, Rohit Yadav 
mailto:rohit.ya...@shapeblue.com>> wrote:
We need the mysql-connector-python rpm because of cloudstack-setup-databases. 
We need python-dns too as it's required by cloudstack-setup-databases.



Regards,

Rohit Yadav

Software Architect, ShapeBlue
https://www.shapeblue.com

rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>
www.shapeblue.com<http://www.shapeblue.com>
@shapeblue




________
From: Paul Angus mailto:paul.an...@shapeblue.com>>
Sent: Tuesday, March 17, 2020 00:07
To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org> 
mailto:dev@cloudstack.apache.org>>
Cc: Rohit Yadav mailto:rohit.ya...@shapeblue.com>>; 
Andrija Panic mailto:andrija.pa...@shapeblue.com>>
Subject: mysql-connector-python


Hi Folks,



Am I correct in thinking that for 4.14, we don’t need to pre-install the python 
connector?
I *think* that it’s still a dependency in the RPMs.  If it is, then we need to 
remove it.



Paul.


Paul Angus
CTO
s: +44 203 603 0540 | m: +44 7711 418784 | d: +44 203 468 5163
e: paul.an...@shapeblue.com<mailto:paul.an...@shapeblue.com>  |  w: 
www.shapeblue.com<http://www.shapeblue.com>  |  t: @cloudyangus @shapeblue
a: 3 London Bridge Street, 3rd floor, News Building, London, SE1 9SG. UK


Find out more about ShapeBlue and our range of CloudStack related services:
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build/> | 
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> | 
CloudStack Software 
Engineering<http://shapeblue.com/cloudstack-software-engineering/>
CloudStack Infrastructure 
Support<http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack 
Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>

Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services 
India LLP is a company incorporated in India and is operated under license from 
Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in 
Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd 
is a company registered by The Republic of South Africa and is traded under 
license from Shape Blue Ltd. ShapeBlue is a registered trademark.This email and 
any attachments to it may be confidential and are intended solely for the use 
of the individual to whom it is addressed. Any views or opinions expressed are 
solely those of the author and do not necessarily represent those of Shape Blue 
Ltd or related companies. If you are not the intended recipient of this email, 
you must neither take any action based upon its contents, nor copy or show it 
to anyone. Please contact the sender if you believe you have received this 
email in error.


--

Andrija Panić

RE: mysql-connector-python

[Paul Angus]

I thought that @Rohit Yadav had added a baked-in client to work around the 
mysql-connector-python Issue.

Have we moved to mysql-connector-python + python-dns instead ?

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


-Original Message-
From: Andrija Panic  
Sent: 16 March 2020 18:58
To: dev 
Cc: Rohit Yadav ; Andrija Panic 

Subject: Re: mysql-connector-python

If not mistaken, that one is needed during setup-cloudstack-databases run, at 
least I recall it was breaking with the newest 8.0.19 and onwards due to some 
missing dns stuff, etc

On Mon, 16 Mar 2020 at 19:38, Paul Angus  wrote:

> Hi Folks,
>
> Am I correct in thinking that for 4.14, we don't need to pre-install 
> the python connector?
> I *think* that it's still a dependency in the RPMs.  If it is, then we 
> need to remove it.
>
> Paul.
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> 3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK 
> @shapeblue
>
>
>
>

-- 

Andrija Panić

mysql-connector-python

[Paul Angus]

Hi Folks,

Am I correct in thinking that for 4.14, we don't need to pre-install the python 
connector?
I *think* that it's still a dependency in the RPMs.  If it is, then we need to 
remove it.

Paul.

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

RE: Primate dependencies

[Paul Angus]

Hi Sven,

I think that it's great.  It can't run anything as low-level as KVM, but for 
anything else it works perfectly and shares the windows filesystem in /mnt/c/

I've run Ansible, Sphinx, Middleman, Kubeadmin, NPM etc in it.

You _can_ use multiple WSLs, and switch between them, although I haven't played 
with that yet.



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


-Original Message-
From: Sven Vogel  
Sent: 23 February 2020 21:17
To: dev@cloudstack.apache.org
Cc: Rohit Yadav 
Subject: Re: Primate dependencies

Really? I use an Mac and I always thought about the new windows sub system and 
is it good. I don’t had a good reference from anybody. Cool ...

Von meinem iPhone gesendet


__

Sven Vogel
Teamlead Platform

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, Frank Richter
Registergericht: Leipzig HRB 9065

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

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.
> Am 23.02.2020 um 22:13 schrieb Paul Angus :
>
> Yep, it runs beautifully!
>
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> 3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK 
> @shapeblue
>
>
>
>
> -Original Message-
> From: Sven Vogel 
> Sent: 23 February 2020 20:20
> To: dev@cloudstack.apache.org
> Cc: Rohit Yadav 
> Subject: Re: Primate dependencies
>
> @Paul you mean really the Windows Sub System for Linux? ;)
>
> Cheers
>
> Sven
>
> Von meinem iPhone gesendet
>
>
> __
>
> Sven Vogel
> Teamlead Platform
>
> 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, Frank Richter
> Registergericht: Leipzig HRB 9065
>
> Zertifiziert nach:
> ISO/IEC 27001:2013
> DIN EN ISO 9001:2015
> DIN ISO/IEC 2-1:2011
>
> 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.
>> Am 23.02.2020 um 09:28 schrieb Paul Angus :
>>
>> @Rohit Yadav<mailto:rohit.ya...@shapeblue.com> I had to update some 
>> dependencies to get everything to install on WSL (Ubuntu 18.04).
>> Is it safe/do you want me to commit these updates to package.json ?
>>
>>
>> -"@antv/data-set": "^0.10.2",
>> +"@antv/data-set": "^0.11.1",
>>
>> -   "ant-design-vue": "~1.4.10",
>> +   "ant-design-vue": "~1.4.11",
>>
>> -  "@vue/test-utils": "^1.0.0-beta.20",  +  "@vue/test-utils":
>> "^1.0.0-beta.31",
>>
>>
>> -  "webpack": "^4.41.5"
>> +   "webpack": "^4.41.6"
>>
>>
>>
>>
>>
>> paul.an...@shapeblue.com
>> www.shapeblue.com
>> 3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK 
>> @shapeblue
>>
>>
>>

RE: Primate dependencies

[Paul Angus]

Yep, it runs beautifully!


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


-Original Message-
From: Sven Vogel  
Sent: 23 February 2020 20:20
To: dev@cloudstack.apache.org
Cc: Rohit Yadav 
Subject: Re: Primate dependencies

@Paul you mean really the Windows Sub System for Linux? ;)

Cheers

Sven

Von meinem iPhone gesendet


__

Sven Vogel
Teamlead Platform

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, Frank Richter
Registergericht: Leipzig HRB 9065

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

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.
> Am 23.02.2020 um 09:28 schrieb Paul Angus :
>
> @Rohit Yadav<mailto:rohit.ya...@shapeblue.com> I had to update some 
> dependencies to get everything to install on WSL (Ubuntu 18.04).
> Is it safe/do you want me to commit these updates to package.json ?
>
>
> -"@antv/data-set": "^0.10.2",
> +"@antv/data-set": "^0.11.1",
>
> -   "ant-design-vue": "~1.4.10",
> +   "ant-design-vue": "~1.4.11",
>
>  -  "@vue/test-utils": "^1.0.0-beta.20",  +  "@vue/test-utils": 
> "^1.0.0-beta.31",
>
>
> -  "webpack": "^4.41.5"
> +   "webpack": "^4.41.6"
>
>
>
>
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> 3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK 
> @shapeblue
>
>
>

Primate dependencies

[Paul Angus]

@Rohit Yadav I had to update some 
dependencies to get everything to install on WSL (Ubuntu 18.04).
Is it safe/do you want me to commit these updates to package.json ?


-"@antv/data-set": "^0.10.2",
+"@antv/data-set": "^0.11.1",

-   "ant-design-vue": "~1.4.10",
+   "ant-design-vue": "~1.4.11",

  -  "@vue/test-utils": "^1.0.0-beta.20",
  +  "@vue/test-utils": "^1.0.0-beta.31",


-  "webpack": "^4.41.5"
+   "webpack": "^4.41.6"





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

RE: [DISCUSS] Honouring listall=true in API calls to include project resources

[Paul Angus]

Ideally, yes.  The use case for 'listall' for the Admin including networks in 
projects, is pretty much the same as for Admins wanting to see VMs and VRs in 
projects... 

It's hard to manage something that you can't see... ☹



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


-Original Message-
From: Rohit Yadav  
Sent: 19 February 2020 09:51
To: Paul Angus ; us...@cloudstack.apache.org; 
dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Honouring listall=true in API calls to include project 
resources

Yes Paul, I've tested for routers and ilbvms - you can test yourself here:

http://primate-qa.cloudstack.cloud:8080/client/master/ (or using cmk)

I just checks, won't work for networks - you want me to fix that?


Regards,

Rohit Yadav

Software Architect, ShapeBlue

https://www.shapeblue.com


From: Paul Angus 
Sent: Wednesday, February 19, 2020 15:02
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Subject: RE: [DISCUSS] Honouring listall=true in API calls to include project 
resources

Does this include networks and VRs?

It's a real pain not being able to see them all..

paul.an...@shapeblue.com
www.shapeblue.com<http://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
  
 


-Original Message-
From: Rohit Yadav 
Sent: 19 February 2020 08:42
To: dev@cloudstack.apache.org; us...@cloudstack.apache.org
Subject: [DISCUSS] Honouring listall=true in API calls to include project 
resources

All,

Many list APIs, such as the listRouters API, accept a `listall` parameter as 
well as a `projectid` parameter. Currently, on calling a list API with 
listall=true and projectid=-1 it only returns resources belonging to all 
projects, the listall=true parameter is effectively ignored.

We've come up with a PR that fixes the list APIs (mainly for Primate) to return 
all the resources including project when both listall=true and projectid=-1 are 
passed, by a non-normal user (i.e. the admin and domain-admin user):

https://github.com/apache/cloudstack/pull/3894/files (the PR also fixed 
incorrect use in old UI)


This will fix the multiple-api calling hack and Primate would be able to say 
list all routers in Infra->Routers with a single API call.

In current UI, for example, to see all the routers under Infra -> Routers, two 
API calls are made with and without projectid=-1. The code in fact ignores the 
listall=true when projectid=-1 is used.


However, this may break "soft" compatibility when both 
listall=true=-1 are passed for some list APIs, as:

  *   Old behaviour: will only returns resources belonging to a project, only 
to admin and domain admin
  *   New behaviour: will return all resources including project resources, 
only to admin and domain admin
  *   Additional notes: normal user (not an admin, or a domain admin etc) will 
not be affected

The listall parameter is documented as "if set to true - list resources that 
the caller is authorized to see", PR intends to fix this behaviour bug.

As far as I can tell the projectid=-1 is only used in the current UI, any 
users, dev want to share their concerns, thoughts?

Regards,

Rohit Yadav

Software Architect, ShapeBlue

https://www.shapeblue.com

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

RE: [DISCUSS] Honouring listall=true in API calls to include project resources

[Paul Angus]

Does this include networks and VRs?

It's a real pain not being able to see them all..

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


-Original Message-
From: Rohit Yadav  
Sent: 19 February 2020 08:42
To: dev@cloudstack.apache.org; us...@cloudstack.apache.org
Subject: [DISCUSS] Honouring listall=true in API calls to include project 
resources

All,

Many list APIs, such as the listRouters API, accept a `listall` parameter as 
well as a `projectid` parameter. Currently, on calling a list API with 
listall=true and projectid=-1 it only returns resources belonging to all 
projects, the listall=true parameter is effectively ignored.

We've come up with a PR that fixes the list APIs (mainly for Primate) to return 
all the resources including project when both listall=true and projectid=-1 are 
passed, by a non-normal user (i.e. the admin and domain-admin user):

https://github.com/apache/cloudstack/pull/3894/files (the PR also fixed 
incorrect use in old UI)


This will fix the multiple-api calling hack and Primate would be able to say 
list all routers in Infra->Routers with a single API call.

In current UI, for example, to see all the routers under Infra -> Routers, two 
API calls are made with and without projectid=-1. The code in fact ignores the 
listall=true when projectid=-1 is used.


However, this may break "soft" compatibility when both 
listall=true=-1 are passed for some list APIs, as:

  *   Old behaviour: will only returns resources belonging to a project, only 
to admin and domain admin
  *   New behaviour: will return all resources including project resources, 
only to admin and domain admin
  *   Additional notes: normal user (not an admin, or a domain admin etc) will 
not be affected

The listall parameter is documented as "if set to true - list resources that 
the caller is authorized to see", PR intends to fix this behaviour bug.

As far as I can tell the projectid=-1 is only used in the current UI, any 
users, dev want to share their concerns, thoughts?

Regards,

Rohit Yadav

Software Architect, ShapeBlue

https://www.shapeblue.com

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

RE: [DISCUSS]/[PROPOSAL] draft PRs

[Paul Angus]

Great work Daan!

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


-Original Message-
From: Daan Hoogland  
Sent: 14 February 2020 18:45
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS]/[PROPOSAL] draft PRs

Thanks all for the swift responses. Let's just start doing this. No need for a 
vote until someone starts a discussion on the subject. Agree?

On Fri, 14 Feb 2020, 17:04 Rohit Yadav,  wrote:

> +1 (better than changing the PR subject, putting wip-labels or [WIP])
>
> Regards,
>
> Rohit Yadav
>
> Software Architect, ShapeBlue
> https://www.shapeblue.com
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> @shapeblue
>
>
>
> --
> *From:* Daan Hoogland 
> *Sent:* Friday, February 14, 2020 17:33
> *To:* dev 
> *Subject:* [DISCUSS]/[PROPOSAL] draft PRs
>
> devs, I thought I had already sent a mail about this but i cannot find it.
> I'm sure i had mentioned it somewhere (probably on github).
> this is a follow up on [1] and hopefully you'll agree, a slight 
> improvement.
>
> here it comes:
>
> At the moment we are creating PRs with a [WIP] or [DO NOT MERGE] tag 
> in the title. This title stands the chance of being merged once we 
> agree the PR is ready for merge. It also clutters the title.
>
> Github has introduced a nice feature a while ago; draft PR. When 
> creating a PR you can opt not to open it for merge but as draft. 
> Choose a button left of the "Create pull request" button, marked 
> "Create draft PR". It will be a full PR with all CI and discussion 
> possibilities open. The only difference is the merge button being 
> disabled. One will than have to make/mark it "ready for merge" before it 
> *can* be merged.
>
> [1]
>
> https://lists.apache.org/thread.html/f3f0988907f85bfc2cfcb0fbcde831037
> f9b1cb017e94bc68932%40%3Cdev.cloudstack.apache.org%3E
> please shoot any comments you may have back at me, thanks
>
> --
> Daan
>

RE: New Joiner

[Paul Angus]

Cool. Welcome Hoang.

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


-Original Message-
From: Wido den Hollander  
Sent: 07 February 2020 08:19
To: dev@cloudstack.apache.org
Subject: Re: New Joiner

Welcome Hoang!

Wido

On 2/7/20 3:13 AM, Hoang Nguyen wrote:
> Hello Everyone,
> 
> My name is Hoang and I'm working for Ewerk. It is my great pleasure to have a 
> chance to join 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 be a part of this team for a long time to go. And I 
> hope to have your kind help.
> Thank you so much.
> 
> Best regards,
> Hoang
> __
> 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 
> 
> 

RE: 4.13 force push apologies

[Paul Angus]

…this makes me feel better about all the times I’ve not done what I thought I 
was doing… no problem Rohit!

From: Daan Hoogland 
Sent: 07 February 2020 08:01
To: dev 
Cc: priv...@cloudstack.apache.org
Subject: Re: 4.13 force push apologies

all good Rohit,
I just did a pull on both branches and no merge happened, so i think you did 
the right thing.


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

On Fri, Feb 7, 2020 at 6:54 AM Rohit Yadav 
mailto:rohit.ya...@shapeblue.com>> wrote:
All,

I made a forward merge error and accidentally merged master into 4.13, rather 
than the opposite (while using Github, should have stick to using zsh to do 
forward merges).

This happened after this commit on 4.13 branch:
https://github.com/apache/cloudstack/commit/d88c614a35107015f211c598282c03f0408f32d2

For reference, I've applied the course correction by resetting --hard the known 
good commit on 4.13, cherry-pick the PRs merged onto 4.13 and force push on 
remote 4.13 branch, and then forward merged the same onto origin/master. I 
further checked the commit SHAs to ensure branch integrities of both 4.13 and 
master, I'll be watching both 4.13 and master smoketests+Travis.

Please accept my apologies for the force push and I hope to have your support. 
Thanks.


Regards,

Rohit Yadav

Software Architect, ShapeBlue

https://www.shapeblue.com

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




--
Daan

RE: [DISCUSS] blocker issue 3646 for 4.14/4.13.1

[Paul Angus]

Thanks.  My vote would be that it is a blocker, as there is no way to clean up 
and so storage filling up and crashing is a very real possibility.


paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 


-Original Message-
From: Andrija Panic  
Sent: 03 February 2020 16:58
To: dev 
Subject: Re: [DISCUSS] blocker issue 3646 for 4.14/4.13.1

I believe not - i.e. you can go and delete the files manually (but in some 
cases there is also records not properly removed from the snapshots_store_ref, 
for either primary or secondary kind, which makes it more complicated...)

I can see Simon has asked his colleague to check it (comments on PR) - fingers 
crossed.

On Mon, 3 Feb 2020 at 17:37, Paul Angus  wrote:

> Is there any kind of workaround or way to 'force' snapshots to be 
> cleaned up (that doesn't create inconsistencies in CloudStack's view 
> of the world vs the physical world?
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> Amadeus House, Floral Street, London  WC2E 9DPUK @shapeblue
>
>
>
>
> -Original Message-
> From: Andrija Panic 
> Sent: 03 February 2020 16:35
> To: dev 
> Subject: Re: [DISCUSS] blocker issue 3646 for 4.14/4.13.1
>
> This issue is here from before (i.e. not new to 4.14), so we can argue
> it's not technically a blocker due to regression happening in some previous
> release, and I can live with it being moved to 4.15.
>
> That being said, would be great to see it solved if this rings any bells
> for anyone who might have played with the related code...
>
> On Mon, 3 Feb 2020 at 13:21, Daan Hoogland 
> wrote:
>
> > People,
> > A ticket has been raised as a blocker but i don't think anybody here
> > has the resources to fix it. It is a regression of kinds, and a known
> > issue but in my not so humble opinion won't block anybody from using a
> > future release. The Issue [1] describes the problem and a PR [2] gives
> > a partial solution. It is known to work for a KVM/Ceph environment and
> > thus might be to specific.
> >
> > I move that we either
> > 1. find the PR that caused this and revert it, and/or 2. postpone
> > fixing it till after 4.14 (unless someone has the resources and
> > volunteers to address it) and as an ugly workaround (creating a cron
> > job for your env that deletes stale images) exists, unmark it as
> > blocker.
> >
> > [1] https://github.com/apache/cloudstack/issues/3646
> > [2] https://github.com/apache/cloudstack/pull/3649
> >
> > any comments, please?
> > --
> > Daan
> >
>
>
> --
>
> Andrija Panić
>


-- 

Andrija Panić

RE: [DISCUSS] blocker issue 3646 for 4.14/4.13.1

[Paul Angus]

Is there any kind of workaround or way to 'force' snapshots to be cleaned up 
(that doesn't create inconsistencies in CloudStack's view of the world vs the 
physical world?

paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 


-Original Message-
From: Andrija Panic  
Sent: 03 February 2020 16:35
To: dev 
Subject: Re: [DISCUSS] blocker issue 3646 for 4.14/4.13.1

This issue is here from before (i.e. not new to 4.14), so we can argue it's not 
technically a blocker due to regression happening in some previous release, and 
I can live with it being moved to 4.15.

That being said, would be great to see it solved if this rings any bells for 
anyone who might have played with the related code...

On Mon, 3 Feb 2020 at 13:21, Daan Hoogland  wrote:

> People,
> A ticket has been raised as a blocker but i don't think anybody here 
> has the resources to fix it. It is a regression of kinds, and a known 
> issue but in my not so humble opinion won't block anybody from using a 
> future release. The Issue [1] describes the problem and a PR [2] gives 
> a partial solution. It is known to work for a KVM/Ceph environment and 
> thus might be to specific.
>
> I move that we either
> 1. find the PR that caused this and revert it, and/or 2. postpone 
> fixing it till after 4.14 (unless someone has the resources and 
> volunteers to address it) and as an ugly workaround (creating a cron 
> job for your env that deletes stale images) exists, unmark it as 
> blocker.
>
> [1] https://github.com/apache/cloudstack/issues/3646
> [2] https://github.com/apache/cloudstack/pull/3649
>
> any comments, please?
> --
> Daan
>


-- 

Andrija Panić

RE: CloudStack Kubernetes provider containers on DockerHub

[Paul Angus]

Just a note to say that I've created a ticket in Apache's Jira as we've not 
heard back from the email...

https://issues.apache.org/jira/browse/INFRA-19792



paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 


-Original Message-
From: Paul Angus  
Sent: 19 January 2020 15:19
To: Sven Vogel ; dev 
Cc: Rohit Yadav ; Pierre-Luc Dion 
; Will Stevens ; 
gabrasc...@gmail.com; Wido den Hollander 
Subject: RE: CloudStack Kubernetes provider containers on DockerHub

I’ve already emailed infra on Thursday Sven, dev@ was in copy.

From: Sven Vogel 
Sent: 17 January 2020 16:13
To: dev 
Cc: Rohit Yadav ; Paul Angus 
; Pierre-Luc Dion ; Will Stevens 
; gabrasc...@gmail.com; Wido den Hollander 

Subject: Re: CloudStack Kubernetes provider containers on DockerHub

Hi Paul,

Yes this sounds interesting and would help to get an consistent state.

@Rohit Do you know how to upload it to "/apache/cloudstack-cloudmonkey“ Maybe 
its the same way like your repo was created.

If we know how to upload we can after that find a way like @Paul said to make 
it automatic and consistent.

I can ask infra to get an information how we get and new area and use existing?

Cheers

Sven




__

Sven Vogel
Teamlead Platform

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

Geschäftsführer:
Dr. Erik Wende, Hendrik Schubert, Frank Richter
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/>

E-World 2020 in Essen.
Das EWERK ist dabei! Treffen Sie uns vom 11-13.02.20 in Halle 5 am Stand: 
5-724, mit spannenden Vorträgen rund um das Thema Urban Data.

Mit Handelsregistereintragung vom 09.07.2019 ist die EWERK RZ GmbH auf die 
EWERK IT GmbH verschmolzen und firmiert nun gemeinsam unter dem Namen: EWERK 
DIGITAL GmbH, für weitere Informationen klicken Sie 
hier<https://www.ewerk.com/ewerkdigital>.

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.
Am 16.01.2020 um 15:39 schrieb Riepl, Gregor (SWISS TXT) 
mailto:gregor.ri...@swisstxt.ch>>:

Hi Rohit,

That surprises me a bit, since the org and name is not specified inside the 
container spec.
You need to be logged into a Docker Hub account that has access to the 
organisation to push containers there.

Regards,
Gregor


From: Rohit Yadav mailto:rohit.ya...@shapeblue.com>>
Sent: 16 January 2020 07:53
To: Paul Angus mailto:paul.an...@shapeblue.com>>; 
dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org> 
mailto:dev@cloudstack.apache.org>>; Sven Vogel 
mailto:s.vo...@ewerk.com>>
Cc: Pierre-Luc Dion mailto:pd...@cloudops.com>>; Will 
Stevens mailto:wstev...@cloudops.com>>; 
gabrasc...@gmail.com<mailto:gabrasc...@gmail.com> 
mailto:gabrasc...@gmail.com>>; Wido den Hollander 
mailto:w...@widodh.nl>>
Subject: Re: CloudStack Kubernetes provider containers on DockerHub

Hi Paul,

I think we added the Dockerfile, I did not actually do anything else. Maybe 
there is a hook that automatically kicks to build and publish container images 
on the apache dockerhub org 
(https://hub.docker.com/r/apache/cloudstack-cloudmonkey). I'm also not part of 
the apache org on dockerhub.

Maybe try adding a Dockerfile if an automatic integration already exists or ask 
asf-dev community?


Regards,

Rohit Yadav

Software Architect, ShapeBlue

https://www.shapeblue.com


From: Paul Angus mailto:paul.an...@shapeblue.com>>
Sent: Wednesday, January 15, 2020 22:30
To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org> 
mailto:dev@cloudstack.

RE: CloudStack Kubernetes provider containers on DockerHub

[Paul Angus]

I’ve already emailed infra on Thursday Sven, dev@ was in copy.

From: Sven Vogel 
Sent: 17 January 2020 16:13
To: dev 
Cc: Rohit Yadav ; Paul Angus 
; Pierre-Luc Dion ; Will Stevens 
; gabrasc...@gmail.com; Wido den Hollander 

Subject: Re: CloudStack Kubernetes provider containers on DockerHub

Hi Paul,

Yes this sounds interesting and would help to get an consistent state.

@Rohit Do you know how to upload it to "/apache/cloudstack-cloudmonkey“ Maybe 
its the same way like your repo was created.

If we know how to upload we can after that find a way like @Paul said to make 
it automatic and consistent.

I can ask infra to get an information how we get and new area and use existing?

Cheers

Sven




__

Sven Vogel
Teamlead Platform

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

Geschäftsführer:
Dr. Erik Wende, Hendrik Schubert, Frank Richter
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/>

E-World 2020 in Essen.
Das EWERK ist dabei! Treffen Sie uns vom 11-13.02.20 in Halle 5 am Stand: 
5-724, mit spannenden Vorträgen rund um das Thema Urban Data.

Mit Handelsregistereintragung vom 09.07.2019 ist die EWERK RZ GmbH auf die 
EWERK IT GmbH verschmolzen und firmiert nun gemeinsam unter dem Namen: EWERK 
DIGITAL GmbH, für weitere Informationen klicken Sie 
hier<https://www.ewerk.com/ewerkdigital>.

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.
Am 16.01.2020 um 15:39 schrieb Riepl, Gregor (SWISS TXT) 
mailto:gregor.ri...@swisstxt.ch>>:

Hi Rohit,

That surprises me a bit, since the org and name is not specified inside the 
container spec.
You need to be logged into a Docker Hub account that has access to the 
organisation to push containers there.

Regards,
Gregor


From: Rohit Yadav mailto:rohit.ya...@shapeblue.com>>
Sent: 16 January 2020 07:53
To: Paul Angus mailto:paul.an...@shapeblue.com>>; 
dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org> 
mailto:dev@cloudstack.apache.org>>; Sven Vogel 
mailto:s.vo...@ewerk.com>>
Cc: Pierre-Luc Dion mailto:pd...@cloudops.com>>; Will 
Stevens mailto:wstev...@cloudops.com>>; 
gabrasc...@gmail.com<mailto:gabrasc...@gmail.com> 
mailto:gabrasc...@gmail.com>>; Wido den Hollander 
mailto:w...@widodh.nl>>
Subject: Re: CloudStack Kubernetes provider containers on DockerHub

Hi Paul,

I think we added the Dockerfile, I did not actually do anything else. Maybe 
there is a hook that automatically kicks to build and publish container images 
on the apache dockerhub org 
(https://hub.docker.com/r/apache/cloudstack-cloudmonkey). I'm also not part of 
the apache org on dockerhub.

Maybe try adding a Dockerfile if an automatic integration already exists or ask 
asf-dev community?


Regards,

Rohit Yadav

Software Architect, ShapeBlue

https://www.shapeblue.com


From: Paul Angus mailto:paul.an...@shapeblue.com>>
Sent: Wednesday, January 15, 2020 22:30
To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org> 
mailto:dev@cloudstack.apache.org>>; Rohit Yadav 
mailto:rohit.ya...@shapeblue.com>>; Sven Vogel 
mailto:s.vo...@ewerk.com>>
Cc: Pierre-Luc Dion mailto:pd...@cloudops.com>>; Will 
Stevens mailto:wstev...@cloudops.com>>; 
gabrasc...@gmail.com<mailto:gabrasc...@gmail.com> 
mailto:gabrasc...@gmail.com>>; Wido den Hollander 
mailto:w...@widodh.nl>>
Subject: RE: CloudStack Kubernetes provider containers on DockerHub

Sorry folks, its been hectic...

Yes Pierre-Luc, we should remove the non-Apache accou

https://hub.docker.com/u/apache

[Paul Angus]

Hi Infra Folks,

Please could you tell us at Apache CloudStack how we upload and maintain images 
on docker hub under the Apache banner?
Are there any policies that we should be aware of?


Many thanks



Paul Angus
Apache CloudStack PMC

paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 

RE: CloudStack Kubernetes provider containers on DockerHub

[Paul Angus]

Sorry folks, its been hectic...

Yes Pierre-Luc, we should remove the non-Apache accounts.

There is an /apache/cloudstack-cloudmonkey repository so it seems @Rohit Yadav 
knows how to get to upload to there @Sven Vogel

I've been working on and off on docker files for building current simulator, as 
well as rpm/deb packaging images.  I was loosely planning to upload a current 
'empty' simulator and a 'populated' simulator with multiple zones, accounts, 
VMs Networks, Firewall rules etc. It was with new UI development in mind.

I was also thinking of a flow where we'd have automation where if there were 
any updates to the dockerfile we could press a button that would create and 
upload new build images.  An RM would be able to use the 'community' image to 
get a consistent outcome.

Probably Feb before I can make them a polished reality.

@Rohit Yadav can you share the process to get docker images pushed to 


Ever the optimist

Paul.


paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 


-Original Message-
From: Sven Vogel  
Sent: 14 January 2020 15:47
To: dev 
Cc: Pierre-Luc Dion ; Will Stevens ; 
gabrasc...@gmail.com; Wido den Hollander 
Subject: Re: CloudStack Kubernetes provider containers on DockerHub

Hi Pierre, Hi Paul,

@Paul do you know how we proceed. How we can get the space from Apache and 
align to the policy?

Cheers

Sven


__

Sven Vogel
Teamlead Platform

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, Frank Richter
Registergericht: Leipzig HRB 9065

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

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.
> Am 13.01.2020 um 15:06 schrieb Pierre-Luc Dion :
>
> Hi Paul,
>
> So we should not use our 2 account but use under apache one instead, 
> correct?  if so, I will remove all owner and projects from the 2 I've 
> created a while back. they are outdated anyway so better hiding them 
> then keep old stuff that can cause confusion.
>
>
> On Sun, Jan 12, 2020 at 4:10 PM Sven Vogel  wrote:
>
>> Hi Paul,
>>
>> I agree! I would do the same If it’s possible.
>>
>> Cheers
>>
>>
>> __
>>
>> Sven Vogel
>> Teamlead Platform
>>
>> 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, Frank Richter
>> Registergericht: Leipzig HRB 9065
>>
>> Zertifiziert nach:
>> ISO/IEC 27001:2013
>> DIN EN ISO 9001:2015
>> DIN ISO/IEC 2-1:2011
>>
>> 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.
>>> Am 12.01.2020 um 21:40 schrieb 

RE: CloudStack Kubernetes provider containers on DockerHub

[Paul Angus]

Hey Guys,

Actually I've been meaning to get round to sorting this. We need to remove 
'our' docker hub account and use the Apache run one
https://hub.docker.com/u/apache

This came up on the Board mailing list with another project. We'll need to 
align ourselves with the policy also.



Kind regards


Paul.

paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 


-Original Message-
From: Sven Vogel  
Sent: 12 January 2020 14:07
To: dev 
Cc: Pierre-Luc Dion ; Pierre-Luc Dion 
; Will Stevens ; 
gabrasc...@gmail.com; Wido den Hollander 
Subject: Re: CloudStack Kubernetes provider containers on DockerHub

Hi Guys,

Should we also find a ways to put the passwords accessible for all committers 
or PMC like Youtube Account?

Make that sense?

Cheers

Sven


__

Sven Vogel
Teamlead Platform

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, Frank Richter
Registergericht: Leipzig HRB 9065

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

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.
> Am 12.01.2020 um 07:17 schrieb Rohit Yadav :
>
> Hi PL,
>
> Thanks for replying. My dockerhub username is 'bhaisaab' [1]. Please add me 
> as an admin to both the groups. We can discuss later if we want to favour one 
> org name vs the other.
>
> [1] https://hub.docker.com/u/bhaisaab/
>
>
> Regards,
>
> Rohit Yadav
>
> Software Architect, ShapeBlue
>
> https://www.shapeblue.com
>
> 
> From: Pierre-Luc Dion 
> Sent: Friday, January 10, 2020 19:24
> To: dev@cloudstack.apache.org 
> Cc: Pierre-Luc Dion ; Will Stevens 
> ; gabrasc...@gmail.com ; 
> Wido den Hollander 
> Subject: Re: CloudStack Kubernetes provider containers on DockerHub
>
> hi, sorry for the late response,
>
> I still have admin access to or cloudstack org on docker hub, [1]  if 
> you want admin access to it, provide me your account name on docker 
> hub and I'll add you to the admin group.
> Quickly looking at it, it's more than overdue, unfortunately all our 
> containers there are outdated :-(
>
> We also have apachecloudstack org name if it's preferable.
>
> These 2 orgs are not subprojects of Apache orgs in docker hub, and 
> probably it would be better to use the apache orgs  ? I don't have any 
> rights on apache docker hub org.
>
> Cheers,
>
>
> [1] https://hub.docker.com/orgs/cloudstack
>
> On Fri, Jan 10, 2020 at 3:07 AM Riepl, Gregor (SWISS TXT) < 
> gregor.ri...@swisstxt.ch> wrote:
>
>> Hello and happy new year to everybody!
>>
>> The k8s provider[1] is still lacking built containers so people can 
>> use it directly.
>> Were you able to figure out how to access the mentioned Docker hub 
>> accounts in the meantime?
>>
>> We can also create a new one if necessary...
>>
>> Thanks,
>> Greg
>>
>>
>> [1] https://github.com/apache/cloudstack-kubernetes-provider
>>
>> 
>> From: Rohit Yadav 
>> Sent: 01 October 2019 12:18
>> To: dev@cloudstack.apache.org ; Pierre-Luc 
>> Dion ; Will Stevens ; 
>> gabrasc...@gmail.com ; Wido den Hollander < 
>> w...@widodh.nl>
>> Subject: Re: CloudStack Kubernetes provider containers on DockerHub
>>
>> Thanks Gregor.
>>
>> Let me tag a few people that may have access to one of the following 
>> docker hub organizations:
>>
>> apache
>> apachecloudstack
>> cloudstack
>>
>>
>> Can you grant access to me (my docker username is 'bhaisaab') and Gregor?
>> Thanks.
>>
>>
>> Regards,
>>
>> Rohit Yadav
>>
>> Software Architect, ShapeBlue
>>
>> https://www.shapeblue.com
>>
>> 
>> From: Riepl, Gregor (SWISS TXT) 
>> Sent: Tuesday, October 1, 2019 14:30
>> To: dev@cloudstack.apache.org 
>> Subject: CloudStack Kubernetes provider containers on DockerHub
>>
>> Hi everyone,
>>
>> We still need to publish the new
>> https://github.com/apache/cloudstack-kubernetes-provider on a public 
>> container registry.
>> It looks like the ASF 

RE: [PROPOSE] RM for 4.14

[Paul Angus]

I can answer that one...

The 'plan' was always 2 new LTS branches a year - effectively summer and 
winter.  Remember at the time, some members of the community were going for a 
release every month. So the idea was - whatever the branch was the current 
branch at the time that an LTS was due, that branch would get some 'extra 
treatment' and be supported for a few years rather than a few months.  

Very importantly, the post x.x.0 LTS releases were to have no new features - 
just bugfixes.  So larger organisations with stricter change control, their own 
documentation and their own integrations, could stay on a 'supported' branch 
but still get bug fixes in releases, without having to worry about, test or 
document new features constantly.

(I'll hand-wave over the fact that one person's feature is another person's 
improvement, is another person's bugfix)

Yes 4.13 is young (and an LTS) so there will undoubtably a 4.13.1 with all 
critical/blocker/major bugfixes in it (probably as soon as enough people have 
recovered from a 4.14 release cycle) but it can't have any new features in it.  

So looking forward, if someone wants a 4.15 release in (say) April, then the 
'summer' LTS branch (July/August time) will be 4.16, if not, then the summer 
LTS release would be 4.15

I hope that helps 


Kind regards

Paul. 


paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 


-Original Message-
From: Gabriel Beims Bräscher  
Sent: 19 December 2019 16:59
To: dev 
Subject: Re: [PROPOSE] RM for 4.14

Hello Andrija,

That is always good news to have contributors stepping up and getting new 
releases done. We definitely need a release (either a major or a 4.13.1.0) to 
keep the project traction. However, I would like to understand why
4.14.0.0 is being considered an LTS release.
As far as I know, the next major release was supposed to be a regular
(non-LTS) release in the midle of the current LTS and next one LTS. Our current 
LTS 4.13.0.0 is young and with still has some room for bugfixes.

For reference, here follows the Release Calendar, more details at [1].
4.9.2.0, LTS, released at 15 December 2016,  EOL 1 July 2018 4.9.3.0, LTS, 
released at 11 September 2017,  EOL 1 July 2018 4.11.0.0, LTS, released at 12 
February 2018,  EOL July 2019 4.12.0.0, Regular, released at 4 April 2019, N/A 
4.13.0.0, LTS, released at 24 September 2019, Current LTS 4.14.0.0, 
LTS/Regular, planned to 21.Feb 2019+

[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS

Regards,
Gabriel.


Em qui., 19 de dez. de 2019 às 17:25, Sven Vogel 
escreveu:

> Hi Andrija,
>
> How can I help and engage in this process?
>
> Cheers
>
> Sven
>
>
>
> __
>
> Sven Vogel
> Teamlead Platform
>
> 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, Frank Richter
> Registergericht: Leipzig HRB 9065
>
> Zertifiziert nach:
> ISO/IEC 27001:2013
> DIN EN ISO 9001:2015
> DIN ISO/IEC 2-1:2011
>
> 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.
> Am 19.12.2019 um 17:05 schrieb Andrija Panic :
> >
> > Hi All,
> >
> > I’d like to put myself forward as release manager for 4.14. The
> > 4.14 releases will be the next major version LTS release and will be 
> > supported for 20 months per the LTS manifesto [2].
> >
> > I'll have support from Rohit/Daan/Paul during the process and anyone 
> > else interested is most welcome to join the effort.
> >
> > The proposed timeline (possibly a bit too ambitious) is as follows:
> >
> > ##
> > 24.Jan 2019   -->   Code freeze
> > 31.Jan-07.Feb 2019 -->   Cut first RC
> > 21.Feb 2019+ -->   Release
> > ##
> >
> > As usual, kindly note the following "behaviour" to be in place 
> > (pretty much copy/paste from the related 4.11 email from Rohit):
> >
> > ##
> > 1. 

RE: [DISCUSS][PROPOSAL]merge policy ratification

[Paul Angus]

Yes, the 'independent verification' could come from one of the LGTM committers, 
although an explanation (+'proof') would still be required for sanity checking. 
  Catching inefficient or poorly written code is important, but no one will 
care that the code is beautifully written, if the SSVM deletes a users' VMs 
because what looked good in theory didn't work in practice. 

It's not about trust, people make mistakes, have bad days, or even get lazy 
occasionally, we have to catch mistakes where we can to make CloudStack as good 
as we can to keep people using it.


paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 


-Original Message-
From: Sven Vogel  
Sent: 10 October 2019 10:48
To: dev@cloudstack.apache.org
Cc: priv...@cloudstack.apache.org
Subject: Re: [DISCUSS][PROPOSAL]merge policy ratification

I think 2 LGTM should be ok if anyone of them has tested it.

The main thing is you need to trust anyway that the person if he has tested it 
E.g. manually.

That’s live and trust from committers I think. Apache is also a chain of trust.

Von meinem iPhone gesendet


__

Sven Vogel
Teamlead Platform

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, Frank Richter
Registergericht: Leipzig HRB 9065

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

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.
> Am 10.10.2019 um 11:43 schrieb Andrija Panic :
>
> Is there a way to "force" some text into the PR description - i.e. 
> like we do for ISSUES (there is some predefined text when creating one).
> My idea ^^^ is to make those rules visible in every PR - besides 
> having rules more explicit, they need to be more visible (as a 
> reminder) to humans pulling the merge trigger.
>
> (I also like the idea of regression-test pass being considered just a 
> starting point for any further testing of the PR)
>
> My objection for some observed PRs:
> 2 x LGTM from purely code review should NOT be enough for merging 
> (assuming regression testing was fine) - perhaps in some realy edge 
> cases where it's 100% clear there is no reason for manual testing 
> (typos fix, simple GUI changes etc).
> At least one LGTM needs to come from the person who did explicit 
> testing - "worksOnMyComputer" (from the submitter of the PR)  is not enough 
> IMHO.
>
> Best,
> Andrija
>
>
>
>> On Thu, 10 Oct 2019 at 10:25, Paul Angus  wrote:
>>
>> BUMP.
>>
>> Hey Guys,
>>
>> We have a lot of new people in the community these days; this seems 
>> like an important exercise to ensure that we're all on the same page, 
>> whether that ends up simply re-signing up to the existing practices 
>> or evolving them.
>>
>> _personally_ I'd like the conditions to be more explicit that there 
>> needs to be some independent verification that the change does what 
>> it's supposed to (and doesn't do anything that it's not supposed to).  
>> It looks to me that sometimes passing regression tests is seen as the 
>> change has been tested.  IMO regression test passing is a 
>> prerequisite of a PR being ready for anyone other than the author(s) to 
>> start reviewing the PR.
>>
>> Cheers
>>
>>
>> Paul.
>>
>>
>>
>> paul.an...@shapeblue.com
>> www.shapeblue.com
>> Amadeus House, Floral Street, London  WC2E 9DPUK @shapeblue
>>
>>
>>
>>
>> -Original Message-
>> From: Daan Hoogland 
>> Sent: 02 October 2019 12:37
>> To: dev 
>> Subject: [DISCUSS][PROPOSAL]merge policy ratification
>>
>> LS,
>> in the past we had set a set of rules in the community under which PR
>> could be merged. I want to rei

RE: [DISCUSS][PROPOSAL]merge policy ratification

[Paul Angus]

BUMP.

Hey Guys,

We have a lot of new people in the community these days; this seems like an 
important exercise to ensure that we're all on the same page, whether that ends 
up simply re-signing up to the existing practices or evolving them.

_personally_ I'd like the conditions to be more explicit that there needs to be 
some independent verification that the change does what it's supposed to (and 
doesn't do anything that it's not supposed to).  It looks to me that sometimes 
passing regression tests is seen as the change has been tested.  IMO regression 
test passing is a prerequisite of a PR being ready for anyone other than the 
author(s) to start reviewing the PR.

Cheers


Paul.



paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 


-Original Message-
From: Daan Hoogland  
Sent: 02 October 2019 12:37
To: dev 
Subject: [DISCUSS][PROPOSAL]merge policy ratification

LS,
in the past we had set a set of rules in the community under which PR could be 
merged. I want to reiterate them here as it seems we are kind of slacking. 
Please chime in if there are any issues or omissions:

For a PR to be merged it has to adhere to the following conditions:
- In any case
-- A PR has to have had two approving reviews
-- A PR has to have no outstanding requests for changes. A request for changes 
is regarded no longer outstanding if the requester stops responding on the PR 
discussions.
-- A PR has to have a review with verification description. Depending on the 
type of PR this can be a test description, an automated test included, 
screenshots in case of UI changes. If it is a tetual change it must be verified 
to not apply to logs or events.
- any commiter can merge a PR if it adheres to those conditions
-- unless a freeze has been called by a the branch it is to be merged on by a 
community appointed release manager for that branch

hope this is short and complete enough at the same time. It has been agreed 
upon in the past but I am too lazy to find the mail thread in the archives.
If anyone disagrees we'll have to go there. They seem reasonable and 
self-evident to me. I am also not sure if these should be stated in bylaws or 
on github, so comments in that respect are welcome as well. Let's first again 
agree on them.

regards,

--
Daan

RE: [VOTE] Primate as modern UI for CloudStack

[Paul Angus]

That sounds great Ivan!  You can see the code at 
https://github.com/shapeBlue/primate
Hopefully within a couple of weeks it'll be able to be included in the Apache 
repo. 

paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 


-Original Message-
From: Ivan Kudryavtsev  
Sent: 09 October 2019 11:08
To: dev 
Subject: Re: [VOTE] Primate as modern UI for CloudStack

Rohit,

we can not afford full-time QA allocation for the project, but let me know when 
you would produce the first piece of the the code, and I'll dedicate someone 
from the QA with Cloudstack experience, who can help you to establish the 
testing environment, choose the tools and write some tests to build a 
foundation, so in the future you and other involved can act by example.

ср, 9 окт. 2019 г. в 16:59, Rohit Yadav :

> Hi Ivan,
>
> Thanks for your advice.
>
> I agree with the general idea of automating regression test for the 
> UI, however, I don't have the expertise around writing tests using 
> best practices, and I look forward to you or anyone else who can share 
> some pointers, examples or maybe a plan. Given the UI is largely 
> config and data driven, the number of components shouldn't be high 
> except for any customization we do for some views.
>
>
> Regards,
>
> Rohit Yadav
>
> Software Architect, ShapeBlue
>
> https://www.shapeblue.com
>
> 
> From: Ivan Kudryavtsev 
> Sent: Wednesday, October 9, 2019 09:37
> To: dev 
> Subject: Re: [VOTE] Primate as modern UI for CloudStack
>
> Hello, community. I know it's just a voting process, but still... a 
> piece of wisdom from webdev company:
>
> 1. Manual testing is an extremely bad idea, you've meet a lot of 
> regression, much more than the backend typically has.
>
> 2. In our teams frontend/backend ratio have shifted from 1/1 to 2/1, 
> without UI automation QA engineers, so 3/1 is average ratio for real 
> life high quality web UIs.
>
> 3. Try to use/invent some sort of Django-like UI generator frameworks, 
> no code manually. I see the high risk of fail without that. May be 
> need to add some sort of metadata to backend first. The Cloudmonkey 
> approach is a great basic idea... Oracle also has certain frameworks 
> for that. Ideally, to define the forms and sitemap and generate everything 
> else from the ORM.
>
> 4. Happy to see the initiative, as it could help to decrease the pace 
> of backend changes and increase the stability, as certain amount of 
> influencers turn into frontend JS developers.
>
>
>
> ср, 9 окт. 2019 г., 7:45 Anurag Awasthi :
>
> > +1
> >
> > Kind Regards,
> > Anurag Awasthi
> > 
> > From: Marco Sinhoreli 
> > Sent: Wednesday, October 9, 2019 4:10 AM
> > To: dev@cloudstack.apache.org ; 
> > us...@cloudstack.apache.org ; 
> > priv...@cloudstack.apache.org 
> > Subject: Re: [VOTE] Primate as modern UI for CloudStack
> >
> > +1
> >
> >
> > Marco Sinhoreli
> > Latam Technical Director
> > marco.sinhor...@shapeblue.com
> > mobile: +55 11 95656-3636
> >
> > Rua Gomes de Carvalho, 911 – Sala 316 Vila Olímpia, São Paulo, SP, 
> > Brasil, 04547-003
> > Phone: + 55 11 2818-3419
> > http://www.shapeblue.com/ | twitter: @shapeblue
> >
> > Em 07/10/2019 08:31, "Rohit Yadav" 
> escreveu:
> >
> > All,
> >
> > The feedback and response has been positive on the proposal to 
> > use Primate as the modern UI for CloudStack [1] [2]. Thank you all.
> >
> > I'm starting this vote (to):
> >
> >   *   Accept Primate codebase [3] as a project under Apache
> CloudStack
> > project
> >   *   Create and host a new repository (cloudstack-primate) and
> follow
> > Github based development workflow (issues, pull requests etc) as we 
> > do
> with
> > CloudStack
> >   *   Given this is a new project, to encourage cadence until its
> > feature completeness the merge criteria is proposed as:
> >  *   Manual testing against each PR and/or with screenshots from
> > the author or testing contributor, integration with Travis is 
> > possible
> once
> > we get JS/UI tests
> >  *   At least 1 LGTM from any of the active contributors, we'll
> > move this to 2 LGTMs when the codebase reaches feature parity wrt 
> > the existing/old CloudStack UI
> >  *   Squash and merge PRs
> >   *   Accept the proposed timeline [1][2] (subject to achievement of
> > goals wrt Primate technical release and GA)
> >  *   the first technical preview targetted with the winter 2019
> > LTS release (~Q1 2020) and release to serve a deprecation notice wrt 
> > the older UI
> >  *   define a release approach before winter LTS
> >  *   stop taking feature FRs for old/existing UI after winter
> 2019
> > LTS release, work on upgrade path/documentation from old UI to Primate
> >  *   the first Primate GA targetted wrt summer LTS 2020 (~H2
> > 2019), but still ship old UI with a final deprecation notice
> >

RE: Failing to download and install cloudstack-agent from deb-repository (Ubuntu 18.04)

[Paul Angus]

@Gabriel Beims Bräscher is there a documented process that you're following 
that we could replicate, I'd like to figure out we can create a Jenkins job 
somewhere that any committer can run to build the packages...


paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 


-Original Message-
From: Gabriel Beims Bräscher  
Sent: 02 October 2019 00:25
To: Rohit Yadav 
Cc: us...@cloudstack.apache.org; Wido den Hollander 
Subject: Re: Failing to download and install cloudstack-agent from 
deb-repository (Ubuntu 18.04)

Hello all,

Cache has been cleaned up and (noredist) packages are now available also for 
Ubuntu (16.04 and 18.04).

Regards,
Gabriel

Em seg, 30 de set de 2019 às 18:25, Gabriel Beims Bräscher < 
gabrasc...@gmail.com> escreveu:

> Hi Rohit and Christoffer,
>
> Ubuntu packages are available now. However, without the 
> non-distributable packages. I will re-check, but so far the noredist 
> packages for Ubuntu are not synced and therefofre casued the issues that 
> Christoffer mentioned.
> Probably a cache issue somewhere on the server.
>
> I will get back with updates as soon as figure out the noredist 
> packages issue. So far packages for CentOS are available with 
> no-redist but 4.13.0.0 packages for Ubuntu are available with normal packages 
> only.
>
> Em seg, 30 de set de 2019 às 07:54, Gabriel Beims Bräscher < 
> gabrasc...@gmail.com> escreveu:
>
>> Hi Rohit,
>>
>> I will regenerate InRelease and packages. Probably the hash mismatch 
>> was caused by the repo partially being updated.
>>
>> I will check this right now.
>>
>> Em seg, 30 de set de 2019 às 06:57, Rohit Yadav < 
>> rohit.ya...@shapeblue.com> escreveu:
>>
>>> + Gabriel, Wido
>>>
>>> Hi Christoffer, thanks for reporting.
>>>
>>> Gabriel, Wido - can you please check and fix. Thanks.
>>>
>>>
>>> Regards,
>>>
>>> Rohit Yadav
>>>
>>> Software Architect, ShapeBlue
>>> https://www.shapeblue.com
>>>
>>> rohit.ya...@shapeblue.com
>>> www.shapeblue.com
>>> @shapeblue
>>>
>>>
>>>
>>> --
>>> *From:* Christoffer Pedersen 
>>> *Sent:* Sunday, September 29, 2019 12:42
>>> *To:* us...@cloudstack.apache.org 
>>> *Subject:* Failing to download and install cloudstack-agent from 
>>> deb-repository (Ubuntu 18.04)
>>>
>>> Hi all,
>>>
>>> Trying for the last few days to install the cloudstack-agent on a 
>>> poc host, however Ubuntu throws a checksum mismatch when using the 
>>> repository..
>>>
>>> Get:1 http://download.cloudstack.org/ubuntu bionic/4.13 all 
>>> cloudstack-common all 4.13.0.0~bionic [55.2 MB]
>>> Err:1 http://download.cloudstack.org/ubuntu bionic/4.13 all 
>>> cloudstack-common all 4.13.0.0~bionic
>>>   File has unexpected size (55213720 != 55212960). Mirror sync in 
>>> progress?
>>> [IP:185.27.174.49 80]
>>>   Hashes of expected file:
>>>-
>>>
>>> SHA512:c61a20d07d5d6e83bdb1301598d87fb05586abccf297071a4eeb90cf62ea34f21e00d98bb4ff7ce9a440e619b732ec0a467baf7a9517b8ac15799ebd5cfd2907
>>>-
>>> SHA256:bbe0f069530acf78b0355493c8562a92a253af05dc9dc5bbd44048e97da74462
>>>- SHA1:6413ecf413775660409229148f348f82d2530697 [weak]
>>>- MD5Sum:fa639279be54120d0c0a3c3c94558c08 [weak]
>>>- Filesize:55212960 [weak]
>>> Get:2 http://download.cloudstack.org/ubuntu bionic/4.13 all 
>>> cloudstack-agent all 4.13.0.0~bionic [50.2 MB]
>>> Err:2 http://download.cloudstack.org/ubuntu bionic/4.13 all 
>>> cloudstack-agent all 4.13.0.0~bionic
>>>   File has unexpected size (50247124 != 50242760). Mirror sync in 
>>> progress?
>>> [IP:185.27.174.49 80]
>>>   Hashes of expected file:
>>>-
>>>
>>> SHA512:8731569fcf52b603eda540c0ac675b8af118360c77f22df88003c26eb3101152d4d59e22cafc42328f190d89260c9dfc04627d4fa15c528c7e2907a5d656be88
>>>-
>>> SHA256:440ae93bd66596f2a77be51b6cb238d5b10931e01a03ff2800b33fb4b691d096
>>>- SHA1:403bd4b0017b9fb5259cd294e44598b25c07a039 [weak]
>>>- MD5Sum:a11875434e024ea21528d00be11caee9 [weak]
>>>- Filesize:50242760 [weak]
>>> E: Failed to fetch
>>>
>>> http://download.cloudstack.org/ubuntu/dists/bionic/4.13/pool/cloudst
>>> ack-common_4.13.0.0~bionic_all.deb
>>>  File has unexpected size (55213720 !=55212960). Mirror sync in progress?
>>> [IP: 185.27.174.49 80]
>>>Hashes of expected file:
>>> -
>>>
>>> SHA512:c61a20d07d5d6e83bdb1301598d87fb05586abccf297071a4eeb90cf62ea34f21e00d98bb4ff7ce9a440e619b732ec0a467baf7a9517b8ac15799ebd5cfd2907
>>> -
>>> SHA256:bbe0f069530acf78b0355493c8562a92a253af05dc9dc5bbd44048e97da74462
>>> - SHA1:6413ecf413775660409229148f348f82d2530697 [weak]
>>> - MD5Sum:fa639279be54120d0c0a3c3c94558c08 [weak]
>>> - Filesize:55212960 [weak]
>>> E: Failed to fetch
>>>
>>> http://download.cloudstack.org/ubuntu/dists/bionic/4.13/pool/cloudst
>>> ack-agent_4.13.0.0~bionic_all.deb  File has unexpected size 
>>> (50247124 !=50242760). Mirror sync in progress?
>>> [IP: 185.27.174.49 80]
>>>Hashes of expected file:
>>> -
>>>
>>> 

RE: 4.13 repo

[Paul Angus]

Thanks @Gabriel Beims Bräscher<mailto:gabrasc...@gmail.com>!

From: Gabriel Beims Bräscher 
Sent: 25 September 2019 21:38
To: Paul Angus 
Cc: dev@cloudstack.apache.org; Wido den Hollander 
Subject: Re: 4.13 repo

Hello @dev / Paul,
Packages are now available for CentOS6, CentOS7, Ubuntu 18.04 and Ubuntu 16.04 
at http://download.cloudstack.org/.
Please, let me know in case anyone has issues installing CloudStack 4.13.0.0 
via the cloudstack.org<http://cloudstack.org> mirrors.
Regards,
Gabriel.

Em ter, 24 de set de 2019 às 09:10, Gabriel Beims Bräscher 
mailto:gabrasc...@gmail.com>> escreveu:
Hi Paul,
No problem, we will take a look at this; will update here when finished 
building and making them available.
Cheers,
Gabriel.

Em ter, 24 de set de 2019 às 06:19, Paul Angus 
mailto:paul.an...@shapeblue.com>> escreveu:
Hi Gabriel/Wido,

I’m about to press send on the 4.13 release announcement. Could you guys build 
the Debian packages for download.cloudstack.org<http://download.cloudstack.org> 
please (as you create them in a fancy way  ), I’ve pushed up the CentOS 
packages.

We should probably look into a centralised Jenkins job or something to do this 
for us each time!

Many thanks


Paul Angus


paul.an...@shapeblue.com<mailto:paul.an...@shapeblue.com>
www.shapeblue.com<http://www.shapeblue.com>
@shapeblue




paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 

RE: [DISCUSS] CloudStack Kubernetes Service plugin

[Paul Angus]

Hi Sven,

The cloudstack-kubernetes-provider is a plugin for Kubernetes which enables 
Kubernetes to drive CloudStack actions, such as opening firewall ports.
The CloudStack Kubernetes service, enables end users to request say, a 
Kubernetes cluster with 1 master and 4 workers (based on a user requested 
service offering).  CloudStack takes care of the plumbing and configuration to 
get the base cluster operational.


paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 


-Original Message-
From: Sven Vogel  
Sent: 25 September 2019 19:18
To: dev 
Cc: us...@cloudstack.apache.org
Subject: Re: [DISCUSS] CloudStack Kubernetes Service plugin

Sounds interesting.

For me there are also some questions like Pierre.

If I understand it correctly all nodes inclusive the masters will be deployed 
from a core os template?
What are the pvc or storage class backend which are available to the cluster 
nodes? (Local storage from the core os vms?)

And now a little bit sorting… what’s the difference between… its a little 
confusing ...

https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Kubernetes+Service
or
https://github.com/apache/cloudstack-kubernetes-provider

Cheers

Sven


__

Sven Vogel
Teamlead Platform

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, Frank Richter
Registergericht: Leipzig HRB 9065

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

Mit Handelsregistereintragung vom 09.07.2019 ist die EWERK RZ GmbH auf die 
EWERK IT GmbH verschmolzen und firmiert nun gemeinsam unter dem Namen: EWERK 
DIGITAL GmbH, für weitere Informationen klicken Sie 
hier<https://www.ewerk.com/ewerkdigital>.

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.

Am 25.09.2019 um 19:29 schrieb Paul Angus 
mailto:paul.an...@shapeblue.com>>:

The FS is here:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Kubernetes+Service

I'll let Abhishek fill in any gaps between whats in the FS and your questions - 
it might be good to comment on the FS so all of this gets captured.
The one thing I would add is that we see this as just the next iteration of the 
feature, not the end goal.  So we would look to add functionality after it goes 
live, but we would also welcome any others wishing to extend the functionality 
too...

Kind regards
Paul.



paul.an...@shapeblue.com
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK @shapeblue




-Original Message-
From: Pierre-Luc Dion 
Sent: 25 September 2019 18:12
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] CloudStack Kubernetes Service plugin

Make sense for the proposed implementation, would it handle redundant master?
How would the k8s cluster would be created, using Rancher tools, kubectl or 
other?

so far, the small part I understand from MaaS, it could be very interesting to 
integrate it to cloudstack in a way where it could be use to  scale Hypervisor 
host, specially KVM nodes.


On Wed, Sep 25, 2019 at 10:47 AM Paul Angus 
wrote:

The proposed implementation will create a master and n worker nodes.
It will also support (graceful) cluster resizing, the next step would be to 
enable the CloudStack plugin for Kubernetes to allow Kubernetes to drive that 
scaling, so that you can scale with demand rather than needing to oversize you 
environment to begin with.

I've been keeping MaaS in mind as way of doing baremetal Kubernetes along side 
VM based Kubernetes clusters.  Interestingly a few people that I have spoken to 
have said that they prefer the use of VMs, because whole servers as the unit of 
scale is often very wasteful, unless you 'share' them whi

RE: [DISCUSS] CloudStack Kubernetes Service plugin

[Paul Angus]

The FS is here:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Kubernetes+Service

I'll let Abhishek fill in any gaps between whats in the FS and your questions - 
it might be good to comment on the FS so all of this gets captured.
The one thing I would add is that we see this as just the next iteration of the 
feature, not the end goal.  So we would look to add functionality after it goes 
live, but we would also welcome any others wishing to extend the functionality 
too...

Kind regards
Paul.



paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 


-Original Message-
From: Pierre-Luc Dion  
Sent: 25 September 2019 18:12
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] CloudStack Kubernetes Service plugin

Make sense for the proposed implementation, would it handle redundant master?
How would the k8s cluster would be created, using Rancher tools, kubectl or 
other?

so far, the small part I understand from MaaS, it could be very interesting to 
integrate it to cloudstack in a way where it could be use to  scale Hypervisor 
host, specially KVM nodes.


On Wed, Sep 25, 2019 at 10:47 AM Paul Angus 
wrote:

> The proposed implementation will create a master and n worker nodes.
> It will also support (graceful) cluster resizing, the next step would 
> be to enable the CloudStack plugin for Kubernetes to allow Kubernetes 
> to drive that scaling, so that you can scale with demand rather than 
> needing to oversize you environment to begin with.
>
> I've been keeping MaaS in mind as way of doing baremetal Kubernetes 
> along side VM based Kubernetes clusters.  Interestingly a few people 
> that I have spoken to have said that they prefer the use of VMs, 
> because whole servers as the unit of scale is often very wasteful, 
> unless you 'share' them which has all sorts of security implications...
>
>
>
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> Amadeus House, Floral Street, London  WC2E 9DPUK @shapeblue
>
>
>
>
> -Original Message-
> From: Pierre-Luc Dion 
> Sent: 25 September 2019 15:31
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] CloudStack Kubernetes Service plugin
>
> Hi Paul,
>
> Yeah, was bad timing for the CCCNA this year unfortunately :-(,  I'm not
> sure I'm curious to see how cloudstack could become more "other Apache
> products friendly" but I don't have particular use case compared to k8s
> integration. Has you are suggesting, would probably make sense to use Helm
> to deploy any other application stack.
>
> btw, we are still working on the Canonical MaaS integration, a bit more
> challenging than anticipated...
>
>
> To get back to a *Kubernetes Service plugin*:
> To me, as a user of cloudstack at the moment, If I deploy a k8s cluster, I
> need to deploy monstrous instances for worker nodes.
> which doesn't make sense if I'm a cloud consumer. So I think we need to
> solve something challenging: a k8s service that would scale has needed
> while keeping in mind redundancy of worker nodes without sacrifice on
> security. Is the worker node is part of the ongoing work or it's more about
> offering a k8s master and api infrastructure to a user ?
>
> An easy path would be some kind of shared worker nodes pool but that
> involve possible security risk unless you would trust users that consume
> those workers.
>
>
> On Wed, Sep 25, 2019 at 10:15 AM Paul Angus 
> wrote:
>
> > Hi Pierre-Luc,
> >
> > (we missed you at CCCNA!) How are you seeing CloudStack being more
> > deployment friendly?  What you do think that we could do on top of
> > creating the Kubenetes Cluster to begin with?
> > [thinking out loud - we could pre-package Tiller to make it easier to
> > deploy openWhisk via Helm charts ? ]
> >
> > Kind regards
> >
> >
> > Paul.
> >
> >
> >
> > paul.an...@shapeblue.com
> > www.shapeblue.com
> > Amadeus House, Floral Street, London  WC2E 9DPUK @shapeblue
> >
> >
> >
> >
> > -Original Message-
> > From: Pierre-Luc Dion 
> > Sent: 25 September 2019 13:37
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] CloudStack Kubernetes Service plugin
> >
> > Hi Rohit, Nux,
> >
> > Thanks Rohit for cloudstack-provider, that's exactly it ! :-D Nux, I
> agree
> > with your opinion, but there is a lot of interest for k8s and seams like
> a
> > lot of organisations are moving to container based infrastructures to
> > standardized their deployment.
> >
> > if we want to extent the discussion to function as a service, would you
> > guys see a possibility for us to be more aligned 

RE: [DISCUSS] CloudStack Kubernetes Service plugin

[Paul Angus]

The proposed implementation will create a master and n worker nodes.
It will also support (graceful) cluster resizing, the next step would be to 
enable the CloudStack plugin for Kubernetes to allow Kubernetes to drive that 
scaling, so that you can scale with demand rather than needing to oversize you 
environment to begin with.

I've been keeping MaaS in mind as way of doing baremetal Kubernetes along side 
VM based Kubernetes clusters.  Interestingly a few people that I have spoken to 
have said that they prefer the use of VMs, because whole servers as the unit of 
scale is often very wasteful, unless you 'share' them which has all sorts of 
security implications...




paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 


-Original Message-
From: Pierre-Luc Dion  
Sent: 25 September 2019 15:31
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] CloudStack Kubernetes Service plugin

Hi Paul,

Yeah, was bad timing for the CCCNA this year unfortunately :-(,  I'm not sure 
I'm curious to see how cloudstack could become more "other Apache products 
friendly" but I don't have particular use case compared to k8s integration. Has 
you are suggesting, would probably make sense to use Helm to deploy any other 
application stack.

btw, we are still working on the Canonical MaaS integration, a bit more 
challenging than anticipated...


To get back to a *Kubernetes Service plugin*:
To me, as a user of cloudstack at the moment, If I deploy a k8s cluster, I need 
to deploy monstrous instances for worker nodes.
which doesn't make sense if I'm a cloud consumer. So I think we need to solve 
something challenging: a k8s service that would scale has needed while keeping 
in mind redundancy of worker nodes without sacrifice on security. Is the worker 
node is part of the ongoing work or it's more about offering a k8s master and 
api infrastructure to a user ?

An easy path would be some kind of shared worker nodes pool but that involve 
possible security risk unless you would trust users that consume those workers.


On Wed, Sep 25, 2019 at 10:15 AM Paul Angus 
wrote:

> Hi Pierre-Luc,
>
> (we missed you at CCCNA!) How are you seeing CloudStack being more 
> deployment friendly?  What you do think that we could do on top of 
> creating the Kubenetes Cluster to begin with?
> [thinking out loud - we could pre-package Tiller to make it easier to 
> deploy openWhisk via Helm charts ? ]
>
> Kind regards
>
>
> Paul.
>
>
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> Amadeus House, Floral Street, London  WC2E 9DPUK @shapeblue
>
>
>
>
> -Original Message-
> From: Pierre-Luc Dion 
> Sent: 25 September 2019 13:37
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] CloudStack Kubernetes Service plugin
>
> Hi Rohit, Nux,
>
> Thanks Rohit for cloudstack-provider, that's exactly it ! :-D Nux, I agree
> with your opinion, but there is a lot of interest for k8s and seams like a
> lot of organisations are moving to container based infrastructures to
> standardized their deployment.
>
> if we want to extent the discussion to function as a service, would you
> guys see a possibility for us to be more aligned or more deployment
> friendly for Openwhisk ?
>
> Cheers,
>
>
> On Wed, Sep 25, 2019 at 6:54 AM Will Stevens 
> wrote:
>
> > We see huge demand for K8s in our customer base. Just a note...
> >
> > On Wed, Sep 25, 2019, 4:03 AM Nux!  wrote:
> >
> > > Do you guys see high demand for K8s?
> > >  From where I'm looking it seems to be going the way of Openstack,
> > > loads of hype, overcomplicated, near-impossible to upgrade.
> > > Not sure if it's worth investing resources for this.
> > >
> > > Lucian
> > >
> > > ---
> > > Sent from the Delta quadrant using Borg technology!
> > >
> > > On 2019-09-24 07:41, Abhishek Kumar wrote:
> > > > Hi all,
> > > >
> > > > I would like to propose developing a plugin for Kubernetes
> > > > integration in CloudStack, can be named CloudStack Kubernetes
> Service plugin.
> > > > I've written down an initial design document for it here,
> > > >
> > >
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Kube
> > rnetes+Service
> > > > Please review and provide your thoughts and suggestions.
> > > >
> > > > Regards,
> > > >
> > > >
> > > > Abhishek Kumar
> > > >
> > > > Software Engineer
> > > >
> > > > ShapeBlue
> > > >
> > > > abhishek.ku...@shapeblue.com
> > > >
> > > > www.shapeblue.com<http://www.shapeblue.com>
> > > >
> > > > abhishek.ku...@shapeblue.com
> > > > www.shapeblue.com
> > > > Amadeus House, Floral Street, London  WC2E 9DPUK @shapeblue
> > >
> >
>
>
> --
>
> *Pierre-Luc Dion*Lead Cloud Architect | Architecte infonuagique principal
> t 1.888.796.8364 ext. 1403
>
>
> <
> https://cloud.ca/?utm_source=email_medium=signature_content=cloud-ca-logo-1_campaign=general_email
> >
>


--

RE: [DISCUSS] CloudStack Kubernetes Service plugin

[Paul Angus]

Hi Pierre-Luc,

(we missed you at CCCNA!) How are you seeing CloudStack being more deployment 
friendly?  What you do think that we could do on top of creating the Kubenetes 
Cluster to begin with?
[thinking out loud - we could pre-package Tiller to make it easier to deploy 
openWhisk via Helm charts ? ]

Kind regards


Paul. 



paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 


-Original Message-
From: Pierre-Luc Dion  
Sent: 25 September 2019 13:37
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] CloudStack Kubernetes Service plugin

Hi Rohit, Nux,

Thanks Rohit for cloudstack-provider, that's exactly it ! :-D Nux, I agree with 
your opinion, but there is a lot of interest for k8s and seams like a lot of 
organisations are moving to container based infrastructures to standardized 
their deployment.

if we want to extent the discussion to function as a service, would you guys 
see a possibility for us to be more aligned or more deployment friendly for 
Openwhisk ?

Cheers,


On Wed, Sep 25, 2019 at 6:54 AM Will Stevens  wrote:

> We see huge demand for K8s in our customer base. Just a note...
>
> On Wed, Sep 25, 2019, 4:03 AM Nux!  wrote:
>
> > Do you guys see high demand for K8s?
> >  From where I'm looking it seems to be going the way of Openstack, 
> > loads of hype, overcomplicated, near-impossible to upgrade.
> > Not sure if it's worth investing resources for this.
> >
> > Lucian
> >
> > ---
> > Sent from the Delta quadrant using Borg technology!
> >
> > On 2019-09-24 07:41, Abhishek Kumar wrote:
> > > Hi all,
> > >
> > > I would like to propose developing a plugin for Kubernetes 
> > > integration in CloudStack, can be named CloudStack Kubernetes Service 
> > > plugin.
> > > I've written down an initial design document for it here,
> > >
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Kube
> rnetes+Service
> > > Please review and provide your thoughts and suggestions.
> > >
> > > Regards,
> > >
> > >
> > > Abhishek Kumar
> > >
> > > Software Engineer
> > >
> > > ShapeBlue
> > >
> > > abhishek.ku...@shapeblue.com
> > >
> > > www.shapeblue.com
> > >
> > > abhishek.ku...@shapeblue.com
> > > www.shapeblue.com
> > > Amadeus House, Floral Street, London  WC2E 9DPUK @shapeblue
> >
>


-- 

*Pierre-Luc Dion*Lead Cloud Architect | Architecte infonuagique principal t 
1.888.796.8364 ext. 1403

Your security@ needs YOU!

[Paul Angus]

HELLO?



Have we enough ‘active’ security representatives?


Please respond if you are ALREADY on the security maililing list and are
still willing/able to assist with CloudStack security issues.

OR

You AREN'T already on the security mailing list, but would like to assist
with security issues. Please note 'people with opinions' are welcome, but
we very much need 'people who can/will do something about' any issues
which are identified.


Kind regards


Paul Angus

[ANNOUNCE] Apache CloudStack 4.13.0.0 GA

[Paul Angus]

*The Apache Software Foundation Announces Apache**®** CloudStack**®** v4.13*


Apache CloudStack v4.13 features nearly 200 new features, enhancements and
fixes since 4.12., such as enhanced hypervisor support, performance
increases and more user-configurable controls.  Highlights include:



   - Supporting configuration of virtualised appliances
   - VMware 6.7 support
   - Increased granularity & control of instance  deployment
   - Improvements in system VM performance
   - Allow live migration of DPDK enabled instances
   - More flexible UI branding
   - Allowing users to create layer 2 network offerings


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



Apache CloudStack powers numerous elastic Cloud computing services,
including solutions that have ranked as Gartner Magic Quadrant leaders.
Highlighted in the Forrester Q4 2017 Enterprise Open Source Cloud Adoption
report, Apache CloudStack "sits beneath hundreds of service provider
clouds", including Fortune 5 multinational corporations. A list of known
Apache CloudStack users are available at
http://cloudstack.apache.org/users.html

4.13 repo

[Paul Angus]

Hi Gabriel/Wido,

I’m about to press send on the 4.13 release announcement. Could you guys build 
the Debian packages for download.cloudstack.org please (as you create them in a 
fancy way  ), I’ve pushed up the CentOS packages.

We should probably look into a centralised Jenkins job or something to do this 
for us each time!

Many thanks


Paul Angus


paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 

RE: CloudStack cwiki write/edit access

[Paul Angus]

You should be good now @Abhishek Kumar.
Let us know if not...

paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 


-Original Message-
From: Abhishek Kumar  
Sent: 23 September 2019 16:16
To: dev@cloudstack.apache.org
Subject: CloudStack cwiki write/edit access

Hi devs,

Can someone please grant me write, edit access on CloudStack cwiki 
https://cwiki.apache.org/confluence/spaces/spacepermissions.action?key=CLOUDSTACK
My username there is shwstppr.
I need to add/update design document for a feature for CloudStack which I'll be 
sharing with community soon.

Regards,

Abhishek Kumar

abhishek.ku...@shapeblue.com
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK @shapeblue
  
 

RE: [DISCUSS] Primate - new UI for CloudStack?

[Paul Angus]

Lol - with great power comes great responsibility David! 

Actually this is a discussion thread, once any issues which people may raise 
are ironed out I expect Rohit will start a VOTE on a concrete proposal and 
timeline.
-- For anyone not used to this process, now would be a good time to explain 
Apache voting rules (https://www.apache.org/foundation/voting.html)

From PMC members on code changes:
+1 = yes I agree, lets do this
0 = I don't mind/care either way
-1 = I object to this change (VETO)

From the rest of the community on code changes:
+1 = yes I agree, lets do this
0 = I don't mind/care either way
-1 = I don't like this change.

As this change would effect so many people, I would hope that any issues would 
be raised during the discussion and a mutually acceptable way forward found, 
before we get as far as a vote.  


Kind regards


Paul Angus





paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 


-Original Message-
From: David Merrill  
Sent: 20 September 2019 18:27
To: us...@cloudstack.apache.org
Subject: Re: [DISCUSS] Primate - new UI for CloudStack?

I love this idea. Separating the UI from the code-base and crafting an API 
driven UI presents excellent opportunities for customizable UIs (and getting 
folks involved with making them) which can improve user experience.

I'd love to get involved and looking forward to trying it out.

+1 (I've never +1'ed anything before, is it OK? Can I vote?) :)

David Merrill
Senior Systems Engineer,
Managed and Private/Hybrid Cloud Services OTELCO
92 Oak Street, Portland ME 04101
office 207.772.5678  
http://www.otelco.com/cloud-and-managed-services
 
Confidentiality Message
The information contained in this e-mail transmission may be confidential and 
legally privileged. If you are not the intended recipient, you are notified 
that any dissemination, distribution, copying or other use of this information, 
including attachments, is prohibited. If you received this message in error, 
please call me at 207.772.5678  so this error can be 
corrected.
 

On 9/20/19, 12:52 PM, "Simon Weller"  wrote:

I like the idea of separating the UI from the main code base. I think that 
will provide a lot more flexibility moving forward and the project is well 
overdue for a new look and feel.

I think the time frame proposed to sunset the old UI is doable and we'll 
need some feedback from those using it today (we have our own UI, so this 
doesn't affect us).

One of our challenges over the last few years is the added work of getting 
UI features into the release and it has added around 30% additional work load 
due to the older style code of the current UI. Having it in VUE is great and I 
think it will also encourage others to contribute.

+1.


From: Anurag A 
Sent: Friday, September 20, 2019 11:26 AM
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: Re: [DISCUSS] Primate - new UI for CloudStack?

+1 to the new UI as it supports:
1. Faster development of features
2. Better experience as a user
3. Easy customisation declaratively

Regards,
Anurag

> On 20-Sep-2019, at 8:17 AM, Siddhartha Kattoju  
wrote:
>
> +1 from me as well.
>
> Just a side note: I feel like there is a high risk of tldr here. May be 
its
> just me. It may be would be good to put most of the details in a wiki page
> and just post a summarized version on the list ?
>
> *Sid Kattoju*
>
> Cloud Software Architect | Professional Services
>
> c 514.466.0951
>
>
> * <https://goo.gl/NYZ8KK>*
>
>
>
>
> On Fri, Sep 20, 2019 at 8:10 AM Rohit Yadav 
> wrote:
>
>> All,
>>
>>
>>
>> == Summary ==
>>
>>
>> I have been working on a new, modern role-based UI for Cloudstack 
(project
>> Primate: https://github.com/shapeblue/primate) I demoed this for the
>> first time at CCCNA19 last week and it was very well received. It was
>> discussed, at length, as an item in the hackathon and the general 
consensus
>> there was that this could become Cloudstacks new UI. We discussed a plan 
to
>> achieve that and now I’m bringing that plan to the list for discussion.
>>
>>
>>
>> == Background ==
>>
>>
>> The current CloudStack UI has grown technical debt over time and it has
>> become harder to extend, develop, maintain in the long run, it is also
>> difficult for new contributors to learn and get started. Since late 
2018, I
>> started working on a side-project with the aim to create a modern
>> progre

Hackathon @apachecon

[Paul Angus]

Hi All,

We have a large room for the day on Wednesday for a hackathon.  I think it 
might be a good idea if we marshal some thoughts around what we'd like to do 
with the time.
I guess that we'll end up with some splinter groups who want to work on 
something very specific together as well, I can't see that being a problem.

Some thing that I'd like to put out there as a discussion is the networking 
models - there has been talk of rationalising and dropping 'basic' networks as 
a separate model and using advanced networks with security groups instead.  
Also the combining of the VR and VPC code to make an isolated network a single 
tier VPC.   I'd like to have a group discussion around what everyone would like 
to do and how we might do it.

Are there any other topics that people think that would benefit from a group 
discussion ?


Cheers


Paul Angus


paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 

[VOTE][RESULT] Apache CloudStack 4.13.0.0

[Paul Angus]

Hi all,

After 3 business days, the vote for CloudStack 4.13.0.0 *passes* with 3 PMC
+ 1 non-PMC votes.

+1 (PMC / binding)
* Gabriel Beims Bräscher
* Boris Stoyanov
* Rohit Yadav

+1 (nonbinding)
* Liridon Ismaili

0
none

-1
none

Thanks to everyone participating.

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


paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 

Re: [VOTE] Apache CloudStack 4.13.0.0 RC2

[Paul Angus]

We're looking good to for a release, but I'm just holding off to hear from 
Gabriel who raised a blocker last time around.

@gabrasc...@gmail.com<mailto:gabrasc...@gmail.com>  are you testing this RC 
(should we wait for you)?


From: Ismaili, Liridon (SWISS TXT) 
Sent: Friday, August 30, 2019 3:54:45 PM
To: dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org 
Subject: Re: [VOTE] Apache CloudStack 4.13.0.0 RC2

Hi Guys,

+1 from our side

Following upgrade was done:
from 4.11.3 to 4.13 RC2
- VMWare 6.5
- Advanced network setup

Post upgrade steps:
- redeployed systemVMs
- redeployed vRouters

Tests done:
- create / started / stopped / destroyed VMs which were created before and 
after the upgrade
- create / restart / cleanup / redundant vRouters
- upload / delete templates and multi disk templates
- create / delete projects / accounts / users

Regards
Liridon

paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 


-Original Message-
From: Paul Angus 
mailto:paul%20angus%20%3cpaul.an...@shapeblue.com%3e>>
Reply-To: us...@cloudstack.apache.org<mailto:us...@cloudstack.apache.org>
To: dev@cloudstack.apache.org 
mailto:%22...@cloudstack.apache.org%22%20%3c...@cloudstack.apache.org%3e>>,
 us...@cloudstack.apache.org 
mailto:%22us...@cloudstack.apache.org%22%20%3cus...@cloudstack.apache.org%3e>>
Subject: [VOTE] Apache CloudStack 4.13.0.0 RC2
Date: Wed, 28 Aug 2019 22:02:32 +


Hi All,


We had an excellently low number of bugs in RC1, so here's RC2 with just 3 
fixes...


I've created a 4.13.0.0 release (RC2), with the following artefacts up for 
testing and a vote:


Git Branch and Commit SH:

<https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.13.0.0-RC20190820T1535>

https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.13.0.0-RC20190820T1535


Commit: 7c7efe76013675b476d8aa14c36a353cd5d429fc


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

<https://dist.apache.org/repos/dist/dev/cloudstack/4.13.0.0/>

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



PGP release keys (signed using 51EE0BC8):

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

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



The vote will be open until 31st August.


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)


Additional information:


For users' convenience, I've built packages from 
7c7efe76013675b476d8aa14c36a353cd5d429fc and published RC1 repository here:

<http://packages.shapeblue.com/testing/41300rc2/>

http://packages.shapeblue.com/testing/41300rc2/



The systemvm templates are unchanged from 4.11.3/4.12.0:

<http://download.cloudstack.org/systemvm/4.11/>

http://download.cloudstack.org/systemvm/4.11/



Fixes in RC2


#3566   server: fix NPE for the case where volume is not attached to a VM

#3567   fix xenserver 7.1.0 os mapping typo

#3571   Unable to deploy VMs via UI in advanced networks with SG and IPv6 cidr





<mailto:paul.an...@shapeblue.com>

paul.an...@shapeblue.com



<http://www.shapeblue.com>

www.shapeblue.com<http://www.shapeblue.com>


Amadeus House, Floral Street, London  WC2E 9DPUK

@shapeblue

[VOTE] Apache CloudStack 4.13.0.0 RC2

[Paul Angus]

Hi All,

We had an excellently low number of bugs in RC1, so here's RC2 with just 3 
fixes...

I've created a 4.13.0.0 release (RC2), with the following artefacts up for 
testing and a vote:

Git Branch and Commit SH:
https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.13.0.0-RC20190820T1535
Commit: 7c7efe76013675b476d8aa14c36a353cd5d429fc

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

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

The vote will be open until 31st August.

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)

Additional information:

For users' convenience, I've built packages from 
7c7efe76013675b476d8aa14c36a353cd5d429fc and published RC1 repository here:
http://packages.shapeblue.com/testing/41300rc2/

The systemvm templates are unchanged from 4.11.3/4.12.0:
http://download.cloudstack.org/systemvm/4.11/

Fixes in RC2

#3566   server: fix NPE for the case where volume is not attached to a VM
#3567   fix xenserver 7.1.0 os mapping typo
#3571   Unable to deploy VMs via UI in advanced networks with SG and IPv6 cidr




paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 

RE: [DISCUSS] Change of the official CHAT channel

[Paul Angus]

I don't think that we should be 'marketing' anything other than the mailing 
lists.That is where most people can be found and where previously asked 
questions can be searched for.
Having a ready to roll 'chat' tool has many advantages, so I'm cool with having 
one in the back pocket.
But personally I'd like to see as little fragmentation of the community as 
possible.

+ a new visitor turning up to a slack channel with 4 people on it is not going 
to give a positive impression, and that person is definitely is far less likely 
to get an answer to any question that they have.

Paul.

paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 


-Original Message-
From: Gabriel Beims Bräscher  
Sent: 23 August 2019 14:56
To: dev 
Cc: Nux! 
Subject: Re: [DISCUSS] Change of the official CHAT channel

Hello folks,

I see no problem with using chat platforms. The mail should stay as the default 
communication tool indeed, but several times I used Slack when helping foes 
around, raising questions, and pinging folks on private chat.
As far as we have tools and they are being used by the community I see no 
problem with keeping them around.

However, I think that the main point raised by Andrija is regarding the 
"marketing" of the channels. We normally promote IRC (pointing to 
irc.freenode.net), but CloudStack IRC channels look pretty dead, especially 
considering that it is the "official" ACS chat tool.

Does promoting all channels (IRC + Slack) look a good idea? Should we keep only 
one option? In one hand, IRC currently is not as active as Slack, but on the 
other hand, Slack requires an invitation e-mail.

Regards,
Gabriel.



Em sex, 23 de ago de 2019 às 08:45, Rohit Yadav 
escreveu:

> All,
>
> I think email is the more persistent form of communication and it must 
> continue to be the default communication mechanism for the project
> dev+user+etc.
>
> For a more real-time/transient communication, IRC or slack are good tools.
> I don't have any preference on either, as I'm not an active user on 
> either of them. It just happened that someone asked me to join the-asf 
> slack for some other group, and I saw many projects having their 
> channels there and I made a comment about it on our current 
> apachecloudstack community slack which is outside of the-asf group. 
> I've got both of them setup on my desktop slack now, if it's too 
> difficult to migrate everyone from the old slack group to the-asf 
> slack group, let's continue as is; or perhaps add an IRC-gateway between the 
> two.
>
>
> Regards,
>
> Rohit Yadav
>
> Software Architect, ShapeBlue
>
> https://www.shapeblue.com
>
> 
> From: Sven Vogel 
> Sent: Friday, August 23, 2019 01:01
> To: dev@cloudstack.apache.org 
> Cc: Nux! 
> Subject: Re: [DISCUSS] Change of the official CHAT channel
>
> Hey Guys,
>
> I don’t understand the problem. I don’t like slack too but I don’t 
> like mailing list or  neither. I think the first one is closed and 
> slow. For me is an mailing list or irc also not the wisdom final 
> conclusion but hey do we have a better one? No.
>
> If IRC is death drop it. If we don’t want slack drop it. leave ONLY 
> the mailing list until there we get an better interactive technology, 
> maybe open source.
>
> Cheers
>
>
> __
>
> Sven Vogel
> Teamlead Platform
>
> EWERK RZ GmbH
> Brühl 24, D-04109 Leipzig
> P +49 341 42649 - 11
> F +49 341 42649 - 18
> s.vo...@ewerk.com
> www.ewerk.com
>
> Geschäftsführer:
> Dr. Erik Wende, Hendrik Schubert, Frank Richter
> Registergericht: Leipzig HRB 17023
>
> Zertifiziert nach:
> ISO/IEC 27001:2013
> DIN EN ISO 9001:2015
> DIN ISO/IEC 2-1:2011
>
> 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.
> > Am 22.08.2019 um 20:28 schrieb Andrija Panic :
> >
> > My whole idea is that having one (IRC) marketed on web pages, while 
> > using the other silently (Slack) makes less than zero sense to me.
> >
> > And, for me, a tool is a tool, I'm not married to