Re: CentOS 8 EOL

[Ron Wheeler]

If you are suggesting that ACS picked a version of Linux, supported it 
with an update repo and guaranteed that it would run forever under ACS 
as long as you kept up with the ACS published updates, that might solve 
a lot of problems for system administrators.
At least there would be a "recommended" Linux that ACS guaranteed would 
run under Cloudstack.


Are there a lot of different functionalities in the various Linux 
versions that make a difference when running applications under Cloudstack?


Can one pick a Linux distribution that would run all the apps that 95% 
of Cloudstack users actually need? It seems that a lot of the 
differences in Linux distributions are in the desktop apps.


Ron

On 2021-12-20 10:18, Nathan McGarvey wrote:

All/any,
 Realistically, since CentOS Stream doesn't have minor versions, I'm
not really sure how you *could* support it. It would be like supporting
CentOS 7.0-7.9, but not knowing which version someone is running. You'd
have to only support the "latest" version as of , which might
be chaos.

 Both Rocky and Alma have fairly decent corporate backers, at least
for the immediate term. (Alma being their parent company pledging
1M/year at least until 2029 to finish out the 8 release cycle, and Rocky
has about 2M/year at the moment, but could flex more.)
 Even Oracle, with their RHEL rebuild could be used in a similar
manner, though I'd probably not recommend them due to their long track
record of open-source interactions being less-than-ideal.

 Perhaps ACS can just pick one of the rebuilds (E.g. Rocky), but
actually publish stuff as just "EL" like EPEL does? It shouldn't really
matter, aside from /etc/os-release files and such. Perhaps ACS can do
what many utilities do and make a "OS Family" determination (Ref:
puppet, ansible, etc.) Instead of a strict "exact same" OS requirement.


Thanks,
-Nathan McGarvey




On 12/16/21 10:40 AM, Nicolas Vazquez wrote:

Hi all,

CentOS 8 will reach EOL on 31st December this year 
-https://www.centos.org/centos-linux-eol/

Opening this thread for discussion on the actions needed: should we drop 
support on the next 4.16.1 release and onwards?

Regards,
Nicolas Vazquez


  





--
Ron Wheeler
Artifact Software
438-345-3369
rwhee...@artifact-software.com

Re: CentOS 8 EOL

[Ron Wheeler]

I was not contemplating leaving Linux so your notes about other Linux 
options is very relevant.


It sounds like you are not concerned that CentOS Stream will be part of 
the QA process for RHEL and have occasional hiccups when updates are 
issued to the LTS version.


Ron


On 2021-12-20 06:51, n...@li.nux.ro wrote:

Hi Ron,

I wouldn't worry about it as much. Although the PR was "managed" 
horribly by RedHat, in technical terms I don't think the situation is 
as dire as it seems.


First of all, CentOS Stream is supported for 5 years, this is as good 
as Ubuntu LTS and knowing RedHat the QA will be much better than 
Canonical's. In fact, CERN deemed it good enough for their use, so if 
Stream is good enough to literally split the atom, then I don't know 
what other endorsement it needs.[1]


Second, there are already many RHEL clones out there, Oracle 
Unbreakable Linux, AlmaLinux, Rocky Linux, plenty to choose from.


And if the situation is still too shaky for your boss, then you could 
always go Ubuntu LTS and last, but not least Debian which is super 
stable and also with 5 years life time.


[1] - 
https://indico.cern.ch/event/1070475/contributions/4511844/attachments/2309304/3929738/lfc03-20210915-NoNDA.pdf



On 2021-12-16 19:36, Ron Wheeler wrote:

As a long-time Centos user, I fear that my company will have to
abandon Centos since Centos is going from a stable, tested system to a
test bed.

This is not really a good move for anyone wanting a reliable 
production system.


It is hard to imaging why anyone would want Centos Steam for 
production use.


Ron

On 2021-12-16 11:40, Nicolas Vazquez wrote:

Hi all,

CentOS 8 will reach EOL on 31st December this year 
-https://www.centos.org/centos-linux-eol/


Opening this thread for discussion on the actions needed: should we 
drop support on the next 4.16.1 release and onwards?


Regards,
Nicolas Vazquez





--
Ron Wheeler
Artifact Software
438-345-3369
rwhee...@artifact-software.com

Re: CentOS 8 EOL

[Ron Wheeler]

As a long-time Centos user, I fear that my company will have to abandon 
Centos since Centos is going from a stable, tested system to a test bed.


This is not really a good move for anyone wanting a reliable production 
system.


It is hard to imaging why anyone would want Centos Steam for production use.

Ron

On 2021-12-16 11:40, Nicolas Vazquez wrote:

Hi all,

CentOS 8 will reach EOL on 31st December this year 
-https://www.centos.org/centos-linux-eol/

Opening this thread for discussion on the actions needed: should we drop 
support on the next 4.16.1 release and onwards?

Regards,
Nicolas Vazquez


  





--
Ron Wheeler
Artifact Software
438-345-3369
rwhee...@artifact-software.com

Re: [DISCUSS] Management server default port conflict

[Ron Wheeler]

Or just chose and register some free ports in a higher range where there 
is less squating.

A lot less code involved by just following the rules.

As an alternative, it might be easy to add a section to the startup 
script with a few lines of netstat|grep to check the ports before trying 
to start.


Ron

On 2020-07-02 2:44 a.m., Wei ZHOU wrote:

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 to configure ClusterManagerImpl

javax.naming.ConfigurationException: Detected that another management

node with the same IP 10.10.2.167 is already running, please check your
cluster configuration

   at

com.cloud.cluster.ClusterManagerImpl.checkConflicts(ClusterManagerImpl.java:1192)

   at

com.cloud.cluster.ClusterManagerImpl.configure(ClusterManagerImpl.java:1065)

   at

org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle$3.with(CloudStackExtendedLifeCycle.java:114)

   at

org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.with(CloudStackExtendedLifeCycle.java:153

Re: [DISCUSS] Management server default port conflict

[Ron Wheeler]

The point is to register so at least people know that the port numbers 
are used if one installs Cloudstack.


If the Cloudstack team at least chooses a set of ports that are not 
currently registered,

1) other projects can avoid using/registering the same ports by mistake
2) other projects that want to use Clodstack ports will know that 
Cloudstack users will be unable to run their apps without some extra effort
3) If another project registers a Cloudstack port, system administrators 
will know *before* they try to go into production that they will have to 
find a solution to the problem rather than having some obscure error 
starting a system that passed all of the tests in the test environment.


My main message is
1) Stop squating on other project's registered ports
2) Whether or not Cloudstack changes default ports, register the ports 
that Cloudstack uses so other projects can avoid squating on Cloudstack 
ports and system admins can see where the conflicts might be.

3) Try to get other projects to follow the rules
4) Change any documentation that shows user-created apps running on 
public ports when they should be running on private/dynamic ports



https://tools.ietf.org/html/rfc6335#section-8.1.2
describes the use of port ranges.
System Ports - 0-1023 - special ports
User Ports - 1024-49151 - for registered port
Dynamic ports - 49152-65535 - private applications and dynamic ports - 
demo apps should be shown running on these ports


There is no shortage of public ports.
Cloudstack is targeted at professional production environment and should 
be a model for other projects and show leadership in adherence to standards.


Ron

On 2020-07-02 5:03 a.m., Paul Angus wrote:

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

Re: [DISCUSS] Management server default port conflict

[Ron Wheeler]

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 to configure ClusterManagerImpl

javax.naming.ConfigurationException: Detected that another management

node with the same IP 10.10.2.167 is already running, please check your
cluster configuration

  at

com.cloud.cluster.ClusterManagerImpl.checkConflicts(ClusterManagerImpl.java:1192)

  at

com.cloud.cluster.ClusterManagerImpl.configure(ClusterManagerImpl.java:1065)

  at

org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle$3.with(CloudStackExtendedLifeCycle.java:114)

  at

org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.with(CloudStackExtendedLifeCycle.java:153)

  at

org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.configure(CloudStackExtendedLifeCycle.java:110)

  at

org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:55)

  at

org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:182)

  at

org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:53)

  at

org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:360)

  at

org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:158

Re: [DISCUSS] Management server default port conflict

[Ron Wheeler]

)
 at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContext(DefaultModuleDefinitionSet.java:144)
 at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet$2.with(DefaultModuleDefinitionSet.java:121)
 at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:244)
 at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:249)
 at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:249)
 at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:232)
 at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContexts(DefaultModuleDefinitionSet.java:116)
 at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.load(DefaultModuleDefinitionSet.java:78)
 at 
org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory.loadModules(ModuleBasedContextFactory.java:37)
 at 
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:70)
 at 
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.(CloudStackSpringContext.java:57)
 at 
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.(CloudStackSpringContext.java:61)
 at 
org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener.contextInitialized(CloudStackContextLoaderListener.java:51)
 at 
org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:930)
 at 
org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:553)
 at 
org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:889)
 at 
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:356)
 at 
org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1445)
 at 
org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1409)
 at 
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:822)
 at 
org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:275)
 at 
org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:524)
 at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
 at 
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
 at 
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:110)
 at 
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97)
 at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.doStart(GzipHandler.java:425)
 at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
 at 
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
 at 
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
 at 
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97)
 at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
 at 
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
 at org.eclipse.jetty.server.Server.start(Server.java:407)

Therefore, in your opinion how this should be handled? Should we document that 
CS management server needs port 9090 free by default and any other process 
using it should be moved a different port or the management server port should 
be moved in case of CentOS8, either in code or documentation to change 
cluster.servlet.port in db.properties?

Regards,
Abhishek

abhishek.ku...@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<http://www.shapeblue.com>
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue




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



--
Ron Wheeler
Artifact Software
438-345-3369
rwhee...@artifact-software.com

Re: New ACS YouTube Channel

[Ron Wheeler]

No problem.
It was an attempt to contribute something! Clara may have already 
figured it out but it was something new to me as well.


Ron

On 2019-11-08 5:21 p.m., Andrija Panic wrote:

Thx for the suggestions Ron, we are no experts so bear with us for a while!

thx

On Fri, 8 Nov 2019, 20:11 Ron Wheeler,
 wrote:


Clare,

https://www.youtube.com/watch?v=-wuwy-a1D1E is a great video about
managing playlists and near the 6 minute mark, she discusses how to
manually sort the videos within the playlist.

I hope that this helps.

Ron

On 2019-11-08 12:37 p.m., Andrija Panic wrote:

All,

Below info on the videos from the recent CloudStack and Ceph days,
held in London on 24.10.2010

And some more news about the new YouTube channel!
(all new recordings will go there, from all the events and all
marketing and similar content)

If anyone wants to be able to contribute/upload to the new YT channel,
please let me know!

Cheers
Andrija

-- Forwarded message -
From: *Clara Herthel* mailto:clara.hert...@shapeblue.com>>
Date: Fri, 8 Nov 2019 at 18:11
Subject: New ACS YouTube Channel
To: market...@cloudstack.apache.org
<mailto:market...@cloudstack.apache.org>
mailto:market...@cloudstack.apache.org


Hello everyone! 珞


It’s been awhile since we last spoken, and there is great news: our
new ACS youtube channel is finally ready.

Me and Andrija have worked on this, we really hope you enjoy the
results. 

The main videos from the old channel (that nobody has the password
for) are reuploaded and we hope this channel can be even more
successful. Talks from the recent CloudStack & Ceph Day are there too.


Channel link: https://www.youtube.com/channel/UCwRLeAHTIaONANmGPOWZN_w

CloudStack & Ceph Day playlist:
https://www.youtube.com/playlist?list=PLnIKk7GjgFlaBqwfrUrqSCiHPVOzgUkQn

(ps: we uploaded the videos neatly but at some point Youtube has
decided to sort the videos in a different way - but I'm trying to
figure out how to fix this)

Any questions, suggestions, ideas, I’m here to answer and work on. 

Hope you all have an amazing weekend!



Kindregards,


Clara.

signature_976398379



*Clara Herthel*

Marketing Coordinator

clara.hert...@shapeblue.com <mailto:clara.hert...@shapeblue.com>

mobile: +55 11 99920-0521 

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



--

Andrija Panić

--
Ron Wheeler
Artifact Software
438-345-3369
rwhee...@artifact-software.com



--
Ron Wheeler
Artifact Software
438-345-3369
rwhee...@artifact-software.com

Re: New ACS YouTube Channel

[Ron Wheeler]

Clare,

https://www.youtube.com/watch?v=-wuwy-a1D1E is a great video about 
managing playlists and near the 6 minute mark, she discusses how to 
manually sort the videos within the playlist.


I hope that this helps.

Ron

On 2019-11-08 12:37 p.m., Andrija Panic wrote:

All,

Below info on the videos from the recent CloudStack and Ceph days, 
held in London on 24.10.2010


And some more news about the new YouTube channel!
(all new recordings will go there, from all the events and all 
marketing and similar content)


If anyone wants to be able to contribute/upload to the new YT channel, 
please let me know!


Cheers
Andrija

-- Forwarded message -
From: *Clara Herthel* <mailto:clara.hert...@shapeblue.com>>

Date: Fri, 8 Nov 2019 at 18:11
Subject: New ACS YouTube Channel
To: market...@cloudstack.apache.org 
<mailto:market...@cloudstack.apache.org> 
mailto:market...@cloudstack.apache.org>>




Hello everyone! 珞


It’s been awhile since we last spoken, and there is great news: our 
new ACS youtube channel is finally ready.


Me and Andrija have worked on this, we really hope you enjoy the 
results. 


The main videos from the old channel (that nobody has the password 
for) are reuploaded and we hope this channel can be even more 
successful. Talks from the recent CloudStack & Ceph Day are there too.



Channel link: https://www.youtube.com/channel/UCwRLeAHTIaONANmGPOWZN_w

CloudStack & Ceph Day playlist: 
https://www.youtube.com/playlist?list=PLnIKk7GjgFlaBqwfrUrqSCiHPVOzgUkQn


(ps: we uploaded the videos neatly but at some point Youtube has 
decided to sort the videos in a different way - but I'm trying to 
figure out how to fix this)


Any questions, suggestions, ideas, I’m here to answer and work on. 

Hope you all have an amazing weekend!



Kindregards,


Clara.

signature_976398379



*Clara Herthel*

Marketing Coordinator

clara.hert...@shapeblue.com <mailto:clara.hert...@shapeblue.com>

mobile: +55 11 99920-0521 

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



--

Andrija Panić


--
Ron Wheeler
Artifact Software
438-345-3369
rwhee...@artifact-software.com

Re: New ACS YouTube Channel

[Ron Wheeler]

You might want to look at the naming of some of the videos.

In the Youtube menu, the video titles are truncated so that many seem to 
have the same title: "#ACSarchives 
<https://www.youtube.com/results?search_query=%23ACSarchives>: Community 
Guy | Networking with...".

You have to mouse over the title to see what the video is about.

For example, "Redundant Routerin  Cloudstack Networking with the 
<https://www.youtube.com/results?search_query=%23ACSarchives> Community 
Guy from the #ACSarchives" or " 
<https://www.youtube.com/results?search_query=%23ACSarchives>Security 
Groupsin  Cloudstack Networking with the 
<https://www.youtube.com/results?search_query=%23ACSarchives> Community 
Guy from the #ACSarchives 
<https://www.youtube.com/results?search_query=%23ACSarchives>" would fix 
this and make the subject easy to see at a glance.


Ron


On 2019-11-08 12:37 p.m., Andrija Panic wrote:

All,

Below info on the videos from the recent CloudStack and Ceph days, 
held in London on 24.10.2010


And some more news about the new YouTube channel!
(all new recordings will go there, from all the events and all 
marketing and similar content)


If anyone wants to be able to contribute/upload to the new YT channel, 
please let me know!


Cheers
Andrija

-- Forwarded message -
From: *Clara Herthel* <mailto:clara.hert...@shapeblue.com>>

Date: Fri, 8 Nov 2019 at 18:11
Subject: New ACS YouTube Channel
To: market...@cloudstack.apache.org 
<mailto:market...@cloudstack.apache.org> 
mailto:market...@cloudstack.apache.org>>




Hello everyone! 珞


It’s been awhile since we last spoken, and there is great news: our 
new ACS youtube channel is finally ready.


Me and Andrija have worked on this, we really hope you enjoy the 
results. 


The main videos from the old channel (that nobody has the password 
for) are reuploaded and we hope this channel can be even more 
successful. Talks from the recent CloudStack & Ceph Day are there too.



Channel link: https://www.youtube.com/channel/UCwRLeAHTIaONANmGPOWZN_w

CloudStack & Ceph Day playlist: 
https://www.youtube.com/playlist?list=PLnIKk7GjgFlaBqwfrUrqSCiHPVOzgUkQn


(ps: we uploaded the videos neatly but at some point Youtube has 
decided to sort the videos in a different way - but I'm trying to 
figure out how to fix this)


Any questions, suggestions, ideas, I’m here to answer and work on. 

Hope you all have an amazing weekend!



Kindregards,


Clara.

signature_976398379



*Clara Herthel*

Marketing Coordinator

clara.hert...@shapeblue.com <mailto:clara.hert...@shapeblue.com>

mobile: +55 11 99920-0521 

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



--

Andrija Panić


--
Ron Wheeler
Artifact Software
438-345-3369
rwhee...@artifact-software.com

Re: [VOTE] Remove el6 support in future CloudStack versions (was Re: [DISCUSS] Remove support for el6 packaging in 4.13/4.14)

[Ron Wheeler]

+1

On 2019-05-21 8:25 a.m., Pierre-Luc Dion wrote:

+1

On Tue, May 21, 2019 at 8:18 AM Wido den Hollander  wrote:


+1

On 5/21/19 11:40 AM, Rohit Yadav wrote:

All,


Thank you for your feedback and discussions. From what we've discussed

so far, we've lazy consensus that nobody wants to use el6 or are limited to
upgrade to el7/el8 due to potential risks.


Moving forward I put forth the following for voting:


- Next minor/major releases (such as 4.11.3.0, 4.13.0.0) will be last

ones to support el6 packaging both for the management server and KVM host,
but users are discouraged from using them

- Next major release (4.13.0.0) will document in its release notes that

we'll stop supporting centos6/rhel6 packaging in future versions, i.e. 4.14
and onwards

- After 4.13.0.0 is released, we will remove el6 related specs,

packaging scripts etc. from the codebase in the master branch


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


** PMCs kindly add binding to your votes, thanks.


Thanks.



Regards,

Rohit Yadav

Software Architect, ShapeBlue

https://www.shapeblue.com



From: Erik Weber 
Sent: Wednesday, April 24, 2019 19:32
To: dev
Subject: Re: [DISCUSS] Remove support for el6 packaging in 4.13/4.14

CentOS7 was released 5 years ago, upgrading is long overdue anyway.
Realistically the next CloudStack release won't be out the door for
another ~4-6 months either.

--
Erik

On Wed, Apr 24, 2019 at 3:27 PM Ron Wheeler
 wrote:

According to https://en.wikipedia.org/wiki/CentOS

CentOS 6 EOL is 2020
CentOS 7 EOL is 2024


+1 for removing support for CentOS 6.

As Erik pointed out the sites running CentOS6 will have to move soon in
any event and it is probably better to do it now when there is still a
lot of current expertise and information available about how to do it
and how to make any changes to applications.

Upgrading in a project that is under your control is usually easier than
one forced on you by a security issue or an operational failure.

Ron

On 4/24/19 3:24 AM, Erik Weber wrote:

As an operations guy I can understand the want for future updates and
not upgrading, but with the release plan of RHEL/CentOS I don't find
it feasible.

RHEL6 is 8 years old (and is still running kernel 2.6!) and isn't
scheduled to be fully EOL until 2024.

It is true that upgrading requires some effort (and risk) from
operators, but this is work they eventually have to do anyway, so it's
not a matter of /if/ they have to do it, but rather when.

It is also true that current CloudStack releases should continue to
work, it's also possible that someone might back port future fixes to
a RHEL6 compatible fork (you're more than welcome to).

I'd vote +1 to remove support for el6 packaging.


rohit.ya...@shapeblue.com
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue





--
Ron Wheeler
Artifact Software
438-345-3369
rwhee...@artifact-software.com

Re: [DISCUSS] Remove support for el6 packaging in 4.13/4.14

[Ron Wheeler]

According to https://en.wikipedia.org/wiki/CentOS

CentOS 6 EOL is 2020
CentOS 7 EOL is 2024


+1 for removing support for CentOS 6.

As Erik pointed out the sites running CentOS6 will have to move soon in 
any event and it is probably better to do it now when there is still a 
lot of current expertise and information available about how to do it 
and how to make any changes to applications.


Upgrading in a project that is under your control is usually easier than 
one forced on you by a security issue or an operational failure.


Ron

On 4/24/19 3:24 AM, Erik Weber wrote:

As an operations guy I can understand the want for future updates and
not upgrading, but with the release plan of RHEL/CentOS I don't find
it feasible.

RHEL6 is 8 years old (and is still running kernel 2.6!) and isn't
scheduled to be fully EOL until 2024.

It is true that upgrading requires some effort (and risk) from
operators, but this is work they eventually have to do anyway, so it's
not a matter of /if/ they have to do it, but rather when.

It is also true that current CloudStack releases should continue to
work, it's also possible that someone might back port future fixes to
a RHEL6 compatible fork (you're more than welcome to).

I'd vote +1 to remove support for el6 packaging.

Re: Any plan for 4.11 LTS extension ?

[Ron Wheeler]

That is written from the point of view of a developer.

From someone who has no desire to ever see the code, let alone change 
it, EOL has a big impact.
In a normal project, in the period prior to EOL, the developers commit 
to fixing bugs and issuing security notices with resolutions.


Cloudstack will have a hard time gaining traction outside the companies 
that develop it, if EOL has no meaning.


I worry that the lack of control over the roadmap and the apparent lack 
of commitment to EOL means that, as good as Cloudstack may be, it is not 
a system for production use unless the user is prepared to take on the 
long-term maintenance at a moments notice and live with uncertainty 
about future viability.


A bit harsh but the conversation about EOL is disturbing.

Ron

On 3/15/19 11:04 AM, Giles Sirett wrote:

Yes - I see your point
I think the thing to bear in mind here is that there is no *formal* EOL for an ACS 
version or branch - its open source - EOL effectively  means that people have lost the 
interest in maintaining that branch.   If people see a demand for more releases on a 
branch in order to maintain that branch  longer- then I'd think it unlikely that anybody 
here is going to say "no"


  maybe the wording in the wiki is misleading



Kind regards
Giles

giles.sir...@shapeblue.com
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
   
  



-Original Message-
From: Jean-Francois Nadeau 
Sent: 15 March 2019 12:49
To: dev@cloudstack.apache.org
Cc: Riepl, Gregor (SWISS TXT) 
Subject: Re: Any plan for 4.11 LTS extension ?

I can only agree with Haijiao,  that 4.11 deserves a longer time span.
Because many bugs are found naturally between the .0 and .1 of the next LTS 
release with it's adoption.

For us 4.11 could only be adopted with 4.11.2.0 after several bugs needed
to get resolved.   So if 4.11's support stops in July then it's time span
was only 6 months from our perspective.

-jfn

On Fri, Mar 15, 2019 at 5:34 AM Wido den Hollander  wrote:



On 3/15/19 10:20 AM, Riepl, Gregor (SWISS TXT) wrote:

Hi Giles,


I would *expect*  4.13.0 (LTS) to be released in Q2, which  will
supersede the 4.11 branch as the current LTS branch

Are you confident that this schedule can be kept?
4.12 is still in RC right now, and I don't think it's a good idea to
rush another major release in just 3 months...


4.11.3 will be released first with some bugfixes to keep 4.11 a proper
release.

4.12 needs to go out now so that we can test and prepare for 4.13. I'm
confident we can have a stable and proper 4.13 release as long as we
don't keep the window open for too long.

The major problem is having the master branch open for a long time,
features going in and people not testing it sufficiently.

By having a relatively short period between 4.12 and 4.13 we can catch
most bugs and stabilize for a proper LTS.

Wido

does cloudstack agent run on alpine?

[Ron Wheeler]

Does cloudstack agent run on alpine? It seems to support kvm

Re: Github Issues

[Ron Wheeler]

I may have voiced my concerns earlier but as a user, I think that JIRA 
issues are easier to follow than PRs.

- As Paul said an issue may affect more than one version.
- It may also require more than one PR to fully resolve the issue.
- Issues tend to be described in terms of a problem that the user would 
recognize while PRs are most often described as what was done to fix the 
problem. The JIRA could be much easier to relate to what the user is 
seeing and more likely to show up in Google.


Ron
On 17/07/2018 4:53 AM, Paul Angus wrote:

Hi All,

We have been trialling replacing Jira with Github Issues.   I think that we 
should have a conversation about it before it become the new standard by 
default.

 From my perspective, I don't like it.  Searching has become far more 
difficult, categorising has also. When there is a bug fix it can only be 
targeted for a single version, which makes them easy to lose track of, and when 
looking at milestones issues and PRs get jumbled up and people are commenting 
on issues when it should by the PR and vice-versa (yes I've done it too).
In summary, from an administrative point of view it causes a lot more problems 
than it solves.

I yield the floor to hear other people's opinions...


Kind regards,

Paul Angus


paul.an...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
   
  



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Cloudstack Collab Canada anyone?

[Ron Wheeler]

1) Work on the website and docs to make Cloudstack look more attractive 
for people looking for a cloud orchestration solution.

- clear description of what it does
- clearly identify target environments - company datacentres, cloud 
service providers, software development teams, etc.
- clear identification of benefits for each target as opposed to other 
solutions

- add customer testimonials from each of the target markets.

2) cleanup roadmap, remove wrong and contradictory information

3) use social media to direct people to the new information.


The team has done a great job in getting a strong presence in the 
presentations


4) put out a regular stream of messaging about each of the presentations 
in social media.
There are some local Montreal groups on social media. I will try to add 
to the list.

- https://twitter.com/technomontreal?lang=en
- https://www.linkedin.com/company/technomontr%C3%A9al/?originalSubdomain=ca
- https://www.meetup.com/cities/ca/qc/montr%C3%A9al/tech/

Perhaps we should develop a list of "important" social media venues and 
regularly share important news on them.



Ron



On 11/07/2018 5:52 AM, Giles Sirett wrote:

All good to hear - looking forward to seeing you all

Whilst we're on this subject, I thought I would chime in with this:

This will be the second year that we've co-located Cloudstack Collaboration 
Conference with Apachecon. Last year (Miami) was really successful: great 
agenda, great talks, really well organised. However, our attendance was down 
compared with all previous CloudStack Collaboration Conferences.

IMO, this was down to the fact that, previously, we had always promoted CCC from within 
the community as it was "our" event. However, last year, I think we all sat 
back a little and expected Apachecon folks to do that.

A lot of work has gone in to putting a great agenda together again 
(http://ca.cloudstackcollab.org/#schedule)


I see  that many people on this list will already be coming (or considering 
coming)  either specifically for Cloudstack collab or to attend the broader 
apachecon talks,  but it would be really great if we can get the attendance up 
from last year.

So, if everybody could help us a little, it would be very much apprecited

Some specific call outs:
1. please share on social media (look for @cloudstack @ApacheCon). Share your 
talk, share others talk, share the conference generally
2. If you're in this community, please make every effort to try and come. These 
conferences really are great for ideas, sharing problems, learning, working 
together, etc
3. Bring others: if you're coming, bring a colleague, bring a customer, bring a 
partner (Montreal is a great City)

Any other ideas?


Kind regards
Giles

giles.sir...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
   
  



-Original Message-
From: Simon Weller 
Sent: 10 July 2018 15:03
To: us...@cloudstack.apache.org
Subject: Re: Cloudstack Collab Canada anyone?

ENA plans to be there as well.





From: David Merrill 
Sent: Tuesday, July 10, 2018 8:17 AM
To: us...@cloudstack.apache.org
Subject: Re: Cloudstack Collab Canada anyone?

And one from Portland, Maine...

David Merrill
Senior Systems Engineer,
Managed and Private/Hybrid Cloud Services OTELCO
92 Oak Street, Portland ME 04101
office 207.772.5678
www.otelco.com<http://www.otelco.com> /business/managed-services

- Original Message -
From: "Andrija Panic" 
To: "users" 
Sent: Tuesday, July 10, 2018 7:00:21 AM
Subject: Re: Cloudstack Collab Canada anyone?

To answer my own question :) from HIAG it will be 3 / 4 of us.

On Tue, Jul 10, 2018, 10:42 Jochim, Ingo  wrote:


Hi all,

from itelligence we will be four guys coming to Montreal.

See you soon.
Regards,
Ingo

-Original Message-
From: Boris Stoyanov [mailto:boris.stoya...@shapeblue.com]
Sent: Dienstag, 10. Juli 2018 10:08
To: users 
Subject: Re: Cloudstack Collab Canada anyone?

Hvala Andrija,

As usual ~all of Shapeblue Egineering team will be present, and
definitely we'll organize something, looking forward!

Boris Stoyanov


boris.stoya...@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue




On 10 Jul 2018, at 10:29, Andrija Panic  wrote:

Hi all,

I was wondering who would be going to Apache CloudStack Collab conference
of 2018 on September 24-26th, Montreal, Canada?

I know it's still early, but if you know, we could (a bit later i.e.
beginning of September) organise some beer sessions or so, after the
official presentation hours are done, catch up, team spirit buildup and
such...

Cheers
Andrija




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [DISCUSS] Blocking the creation of new Basic Networking zones

[Ron Wheeler]

Please propose a new network documentation page as part of this discussion.

If it  makes it more palatable to developers, we could rename the 
documentation to "Use Cases".


That would make it easier to discuss the real impact on users of what is 
being proposed.


The current network documentation is one of the biggest barriers to 
entry and generates a lot of the traffic in the forum.


Ron


On 06/07/2018 4:50 AM, Paul Angus wrote:

Sorry for being late to the party.

'in theory' couldn't we do away with the idea that 'advanced networking with 
security groups' is a type of zone and just allow the use of security groups in 
any network, instead of making people 'choose' up front.
I believe AWS allows the use of security groups in VPCs.  It seems a little 
'belt and braces', but I know of users who have looked to do it.



Kind regards,

Paul Angus

paul.an...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
   
  



-Original Message-
From: Wido den Hollander 
Sent: 19 June 2018 21:58
To: dev@cloudstack.apache.org
Subject: [DISCUSS] Blocking the creation of new Basic Networking zones

Hi,

We (PCextreme) are a big-time user of Basic Networking and recently started to 
look into Advanced Networking with VLAN isolation and a shared network.

This provides (from what we can see) all the features Basic Networking 
provides, like the VR just doing DHCP and UserData while the Hypervisor does 
the Security Grouping.

That made me wonder why we still have Basic Networking.

Dropping all the code would be a big problem for users as you can't simply 
migrate from Basic to Advanced. In theory we found out that it's possible by 
changing the database, but I wouldn't guarantee it works in every use-case. So 
doing this automatically during a upgrade would be difficult.

To prevent us from having to maintain the Basic Networking code for ever I 
would like to propose and discuss the matter of preventing the creation of new 
Basic Networking zones.

In the future this can get us rid of a lot of if-else statements in the code 
and it would make testing also easier as we have few things to test.

Most of the development also seems to go in the Advanced Networking direction.

We are currently also working on IPv6 in Advanced Shared Networks and that's 
progressing very good as well.

Would this be something to call the 5.0 release where we simplify the 
networking and in the UI/API get rid of Basic Networking while keeping it alive 
for existing users?

Wido



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Fwd: Re: Page update question

[Ron Wheeler]

I received this from Apache about the process to update the Cloudstack 
project page.


I hope that this will allow the PMC to update the release information as 
well as any other information on that page.


Ron

 Forwarded Message 


The projects site is officially managed by ComDev but the content is
dependent on the projects keeping their information up to date. I did a
quick search and found this that gives some basic instructions (How the
Code Works section) and links for what needs to be done.

https://projects.apache.org/about.html

I hope this helps.

Thanks
Sharan

On 27.6.2018 16:57, Ron Wheeler wrote:

https://projects.apache.org/project.html?cloudstack

This page is badly out of date and no one in the project seems to know 
how to fix it.


Is there a page describing how the PMC should update it?

Ron

Re: John Kinsella and Wido den Hollander now ASF members

[Ron Wheeler]

Congratulations!

Ron
On 02/05/2018 3:53 PM, Erik Weber wrote:

ons. 2. mai 2018 kl. 17:58 skrev David Nalley <da...@gnsa.us>:


Hi folks,

As noted in the press release[1] John Kinsella and Wido den Hollander
have been elected to the ASF's membership.

Members are the 'shareholders' of the foundation, elect the board of
directors, and help guide the future of the ASF.

Congrats to both of you, very well deserved.


Congratulations to both of you :-)

Erik



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Default API response type: XML -> JSON

[Ron Wheeler]

The time would be better spent on fixing the docs.

It is time to turn Cloudstack into a production quality product with 
documentation that actually reflects the quality of the design and 
functionality.


At the moment you have 2 people willing to work on the docs waiting for 
a committer to decide that professional documentation matters.


This proposal seems to make the product more complicated with no 
substantial benefit.
Parsing XML is a well-known technology and switching to JSON does not 
seem to reduce the code required or reduce the complexity of the code.


If there is a desire to me "more modern", fix the documentation.


On 24/04/2018 6:14 AM, Marc-Aurèle Brothier wrote:

@rafael - I think it's overkill to have this as a configuration option. We
should have one default response type, or maybe not have a default one and
enforce the use of the response type the client is willing to receive.

On Mon, Apr 23, 2018 at 3:39 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:


I do think it is an interesting proposal. I have been thinking, and what if
we do something different; what about a global parameter where the root
admin can define the default serialization mechanism (XML, JSON, RDF,
others...)? The default value could be XML to maintain backward
compatibility. Then, it is up to the root admin to define this behavior.


On Mon, Apr 23, 2018 at 10:34 AM, Marc-Aurèle Brothier <ma...@exoscale.ch>
wrote:


Hi everyone,

I thought it would be good to move from XML to JSON by default in the
response of the API if no response type is sent to the server along with
the request. I'm wondering that's the opinion of people on the mailing
list.

Moreover, if anyone knows a tool working with the API in XML can you list
them, so I could check the code and see if the change can be done without
breaking it.

PR to change default response type: (
https://github.com/apache/cloudstack/pull/2593).
If this change would cause more trouble, or is not needed in your

opinion,

I don't mind to close the PR.

Kind regards,
Marc-Aurèle




--
Rafael Weingärtner



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [DISCUSS] Why we MARK packets?

[Ron Wheeler]

https://markandruth.co.uk/2016/08/08/testing-the-performance-of-the-linux-firewall
Does not directly address marking but does benchmark a number of 
iptables filtering tasks which may give some insight into the 
performance implications of using iptables for routing and filtering.


https://www.digitalocean.com/community/tutorials/a-deep-dive-into-iptables-and-netfilter-architecture
A nice article on iptables. No performance info but a good read for 
anyone who needs to tackle routing and marking.


 https://www.markusschade.com/papers/firewall.pdf
Has some performance info and a discussion about the host limit with MARK.

I am a bit skeptical that MARK adds a lot of overhead but this is only 
based on the belief that CPUs are orders of magnitude faster than networks.
The decision process on entry and exit are both pretty simple and 
depending on the implementation of the internal table should not take a 
lot of memory of CPU to do the table lookups


I did not read all 60,400 links returned by Google but in the ones that 
I did read did not warn of any big problem with performance using MARK.


I use a simple static MARK configuration in my firewall to solve a 
routing problem but the performance requirements are not relevant to an 
datacentre with hundreds of CPUs and hundreds of entries in the MARK 
routing map.


I hope that this helps.

Ron


On 20/04/2018 9:04 AM, Rohit Yadav wrote:

Thanks Jayapal. I don't have any comparative study yet, but I'll explore this 
in future if we can get away without marking (mangling) packets which is 
generally an expensive task.


- Rohit

<https://cloudstack.apache.org>




From: Jayapal Uradi <jayapal.ur...@accelerite.com>
Sent: Thursday, April 19, 2018 10:33:25 AM
To: dev@cloudstack.apache.org
Cc: us...@cloudstack.apache.org
Subject: Re: [DISCUSS] Why we MARK packets?

Rohit,

My comments inline.


rohit.ya...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
   
  


On Apr 19, 2018, at 1:52 AM, Rohit Yadav 
<rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>> wrote:

Nevermind, found the use of custom routing tables. In case someone want to 
refer, hints are here:

https://github.com/apache/cloudstack/pull/2514#issuecomment-382510915


Jayapal and others - I've another one, is there a way to do routing without 
marking packets at all, even in case of VRs with additional public interfaces?

AFAIK marking is the only way to do it.
Do you have any performance numbers with and without mark rules.

- Rohit

<https://cloudstack.apache.org<https://cloudstack.apache.org/>>




From: Rohit Yadav <rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>>
Sent: Wednesday, April 18, 2018 10:39:02 PM
To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>; 
us...@cloudstack.apache.org<mailto:us...@cloudstack.apache.org>
Subject: [DISCUSS] Why we MARK packets?

All,


I could not find any history around 'why' we MARK or CONNMARK packets in mangle 
table in VRs? I found an issue in case of VPCs where `MARK` iptable rules 
failed hair-pin nat (as described in this PR: 
https://github.com/apache/cloudstack/pull/2514)


The valid usage I found was wrt VPN_STATS, however, the usage is not exported 
at all, it is commented:

https://github.com/apache/cloudstack/blob/master/systemvm/debian/opt/cloud/bin/vpc_netusage.sh#L141


Other than for debugging purposes in the VR, marking packets and connections I 
could not find any valid use. Please do share if you're using marked packets 
(such as VPN ones etc) outside of VR scope?


I propose we remove MARK on packets which is cpu intensive and slows the 
traffic (a bit), instead CONNMARK can still be used to mark connections and 
debug VRs without actually changing the packet marking permanently. Thoughts?


- Rohit

<https://cloudstack.apache.org>



rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>
www.shapeblue.com<http://www.shapeblue.com/><http://www.shapeblue.com<http://www.shapeblue.com/>>
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue




rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>
www.shapeblue.com<http://www.shapeblue.com/>
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue

DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infecte

Re: Community opinion regarding Apache events banner in CloudStack's website

[Ron Wheeler]

I wish that there was this much excitement about the problems in the 
installation docs!


Lets make a decision and live with layout for a few weeks and see how 
placement number 3 affects the community and how many people who did not 
plan to go to ApacheCon decide to go because of the placement of the 
event link.


Ron
On 18/04/2018 7:56 AM, Will Stevens wrote:

I vote 4

On Wed, Apr 18, 2018, 7:13 AM Rafael Weingärtner, <
rafaelweingart...@gmail.com> wrote:


I am confused as well. Here goes a link with all image suggestions [1]. The
tally so far is the following:

- Option 1  (banner in the middle of the main CloudStack section)- 1
vote (Rafael)
- Option 2  (a new section called “Apache events”)- 1 vote (Gabriel)
- Option 3 (Banner aligned right and under CloudMonkey image – we can
apply some improvements suggested by Nitin here) – 8 votes (Dag, Swen,
Stephan, Boris, Ron, Grégorie, Nitin, Mauricio)
- Option 4  (aligned left) – 1 vote (Nicolás)


[1] https://drive.google.com/open?id=1dqjPI2PBZ3hvKr2eEWaH3Fj_hLhXUxvB

On Wed, Apr 18, 2018 at 8:06 AM, Will Stevens <wstev...@cloudops.com>
wrote:


Can we list the options and their voting numbers?  I am a bit confused
right now.

I like the one that is left aligned under the text and keeps the logo on
the right full size.

On Tue, Apr 17, 2018, 10:41 PM Nitin Maharana, <nitin.mahar...@gmail.com

wrote:


+1 for the third option. I think It would even look good if we adjust

the

vertical alignment of the word "Apache CloudStack" to center.

On Wed, Apr 18, 2018 at 12:12 AM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:


Third option (suggested by Dag) -
https://drive.google.com/open?id=16FEu9tD1HZqwxLp2lrnUBmsuRJNLpDqU

On Tue, Apr 17, 2018 at 3:39 PM, Dag Sonstebo <

dag.sonst...@shapeblue.com>

wrote:


Hi Rafael – in my opinion you need it fairly prominent so people

notice

it

– so option 1, but maybe put it underneath the CloudMonkey logo on

the

right hand side?

Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue

On 17/04/2018, 19:35, "Rafael Weingärtner" <

rafaelweingart...@gmail.com>

wrote:

 Ah damm.. I forgot about the file stripping in our mailing

list.

 Sorry guys. Here they go.

 - first one:
 https://drive.google.com/open?id=1vSqni_GEj3YJjuGehxe-_

dnrNqQP7x8y

 - second one:


https://drive.google.com/open?id=1LEmt9g5ceAUeTuc2a1Cb4uctOwyz5

eQ8

 On Tue, Apr 17, 2018 at 3:31 PM, Dag Sonstebo <
dag.sonst...@shapeblue.com>
 wrote:

 > The white one is quite nice ☺
 >
 > Joking aside – looks like they got stripped from your email

Rafael.

 >
 > Regards,
 > Dag Sonstebo
 > Cloud Architect
 > ShapeBlue
 >
 > From: Rafael Weingärtner <rafaelweingart...@gmail.com>
 > Reply-To: "dev@cloudstack.apache.org" <

dev@cloudstack.apache.org

 > Date: Tuesday, 17 April 2018 at 19:13
 > To: users <us...@cloudstack.apache.org>, dev <
dev@cloudstack.apache.org>
 > Subject: Community opinion regarding Apache events banner in
CloudStack's
 > website
 >
 > Hello folks,
 > I am trying to work out something to put Apache events banner

on

our

 > website. So far I came up with two proposals. Which one of

them

do

you guys
 > prefer?
 > First one:
 > [cid:ii_jg3zjco00_162d4ce7db0cd3da]
 >
 >
 > Second:
 > [cid:ii_jg3zk0e01_162d4cefaef3a1ce]
 >
 > --
 > Rafael Weingärtner
 >
 > dag.sonst...@shapeblue.com
 > www.shapeblue.com
 > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
 > @shapeblue
 >
 >
 >
 >


     --
     Rafael Weingärtner



dag.sonst...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue






--
Rafael Weingärtner




--
Rafael Weingärtner



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Host KVM Installation - tcp ports

[Ron Wheeler]

http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/4.11/hypervisor/kvm.html
Identifies a number of ports that must be opened.

It specifies a number of Dynamic/Private ports: 49152 - 49216 (libvirt 
live migration)


The Cloudstack doc does not recommend reserving these ports.
They could be assigned by the OS for other tasks.
I am not sure if anyone has run into random errors in this area but I 
think that it would be a good idea to use sysctl to reserve these ports 
and remove them from the dynamic ports available to the OS or other 
random programs that use dynamically assigned ports.


Add the following to /etc/sysctl to have these ports removed from the OS 
list of available dynamic ports.


|sysctl -w net.ipv4.ip_local_reserved_ports = 49152-49216|

https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

For some reason the libvrt guys have not registered their ports (16509, 
16514) so we could all be in for a surprise when that port gets assigned 
to another program. We can only hope that the program is not one that is 
needed by Cloudstack.


https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

If anyone is contact with the authors of libvrt, it would be a good idea 
to suggest to them that they reserve the ports that they need.
I think that it is safe to assume that libvrt will be around for a while 
and having these ports reserved makes sense.


I am not sure why Cloudstack requires port 1798. It is reserved for 
EventTransfer Protocol (etp).

Is this the service that Cloudstack uses or another case of a hijacked port?

Ron

Re: Community opinion regarding Apache events banner in CloudStack's website

[Ron Wheeler]

That is great.
A very nice touch from someone who is clearly thinking about how to get 
support for Apache without adding to the PMC's workload.


Ron

On 17/04/2018 3:14 PM, Rafael Weingärtner wrote:

It seems that we have a consensus here.

I do not think so Ron. If I read correctly what I received in the PMC 
list:


If you follow these steps, it will automatically update for the next
event, and the one after that. We have two other events planned for
this year, and are already working on 5 events for 2019.


The icon should update itself to the next Apache event automatically.

On Tue, Apr 17, 2018 at 4:11 PM, Ron Wheeler 
<rwhee...@artifact-software.com 
<mailto:rwhee...@artifact-software.com>> wrote:


The one at the top of the page has the most impact.
Have to remember to take it down after the conference.

Ron


On 17/04/2018 2:35 PM, Rafael Weingärtner wrote:

Ah damm.. I forgot about the file stripping in our mailing list.
Sorry guys. Here they go.

- first one:
https://drive.google.com/open?id=1vSqni_GEj3YJjuGehxe-_dnrNqQP7x8y
<https://drive.google.com/open?id=1vSqni_GEj3YJjuGehxe-_dnrNqQP7x8y>

- second one:
https://drive.google.com/open?id=1LEmt9g5ceAUeTuc2a1Cb4uctOwyz5eQ8
<https://drive.google.com/open?id=1LEmt9g5ceAUeTuc2a1Cb4uctOwyz5eQ8>

On Tue, Apr 17, 2018 at 3:31 PM, Dag Sonstebo
<dag.sonst...@shapeblue.com <mailto:dag.sonst...@shapeblue.com>>
wrote:

The white one is quite nice ☺

Joking aside – looks like they got stripped from your
email Rafael.

Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue

From: Rafael Weingärtner <rafaelweingart...@gmail.com
<mailto:rafaelweingart...@gmail.com>>
Reply-To: "dev@cloudstack.apache.org
<mailto:dev@cloudstack.apache.org>"
<dev@cloudstack.apache.org <mailto:dev@cloudstack.apache.org>>
Date: Tuesday, 17 April 2018 at 19:13
To: users <us...@cloudstack.apache.org
<mailto:us...@cloudstack.apache.org>>, dev
<dev@cloudstack.apache.org <mailto:dev@cloudstack.apache.org>>
Subject: Community opinion regarding Apache events banner
in CloudStack's
website

Hello folks,
I am trying to work out something to put Apache events
banner on our
website. So far I came up with two proposals. Which one of
them do you guys
prefer?
First one:
[cid:ii_jg3zjco00_162d4ce7db0cd3da]


Second:
[cid:ii_jg3zk0e01_162d4cefaef3a1ce]

--
Rafael Weingärtner

dag.sonst...@shapeblue.com <mailto:dag.sonst...@shapeblue.com>
www.shapeblue.com <http://www.shapeblue.com>
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue






-- 
Ron Wheeler

President
Artifact Software Inc
email: rwhee...@artifact-software.com
<mailto:rwhee...@artifact-software.com>
skype: ronaldmwheeler
phone: 866-970-2435, ext 102




--
Rafael Weingärtner



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Community opinion regarding Apache events banner in CloudStack's website

[Ron Wheeler]

The one at the top of the page has the most impact.
Have to remember to take it down after the conference.

Ron

On 17/04/2018 2:35 PM, Rafael Weingärtner wrote:

Ah damm.. I forgot about the file stripping in our mailing list.
Sorry guys. Here they go.

- first one:
https://drive.google.com/open?id=1vSqni_GEj3YJjuGehxe-_dnrNqQP7x8y

- second one:
https://drive.google.com/open?id=1LEmt9g5ceAUeTuc2a1Cb4uctOwyz5eQ8

On Tue, Apr 17, 2018 at 3:31 PM, Dag Sonstebo <dag.sonst...@shapeblue.com>
wrote:


The white one is quite nice ☺

Joking aside – looks like they got stripped from your email Rafael.

Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue

From: Rafael Weingärtner <rafaelweingart...@gmail.com>
Reply-To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Date: Tuesday, 17 April 2018 at 19:13
To: users <us...@cloudstack.apache.org>, dev <dev@cloudstack.apache.org>
Subject: Community opinion regarding Apache events banner in CloudStack's
website

Hello folks,
I am trying to work out something to put Apache events banner on our
website. So far I came up with two proposals. Which one of them do you guys
prefer?
First one:
[cid:ii_jg3zjco00_162d4ce7db0cd3da]


Second:
[cid:ii_jg3zk0e01_162d4cefaef3a1ce]

--
Rafael Weingärtner

dag.sonst...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue








--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [DISCUSS] CloudStack graceful shutdown

[Ron Wheeler]

servers (MSs)
execute; are
 > > >> these
 > > >> tasks originate from requests that come to the MS, or is it
possible
 > > that
 > > >> requests received by one management server to be executed by
other? I
 > > >> mean,
 > > >> if I execute a request against MS1, will this request always be
 > > >> executed/threated by MS1, or is it possible that this request is
 > > executed
 > > >> by another MS (e.g. MS2)?
 > > >>
 > > >> * I would suggest that after we block traffic coming from
 > > >> 8080/8443/8250(we
 > > >> will need to block this as well right?), we can log the
execution of
 > > >> tasks.
 > > >> I mean, something saying, there are XXX tasks (enumerate tasks)
still
 > > >> being
 > > >> executed, we will wait for them to finish before shutting down.
 > > >>
 > > >> * The timeout (60 minutes suggested) could be global settings
that we
 > > can
 > > >> load before executing the graceful-shutdown.
 > > >>
 > > >> On Wed, Apr 4, 2018 at 5:15 PM, ilya musayev <
 > > >> ilya.mailing.li...@gmail.com<mailto:ilya.mailing.lists@
gmail.com>
 > > >>
 > > >> wrote:
 > > >>
 > > >> Use case:
 > > >> In any environment - time to time - administrator needs to
perform a
 > > >> maintenance. Current stop sequence of cloudstack management
server
     > will
 > > >> ignore the fact that there may be long running async jobs - and
 > > >> terminate
 > > >> the process. This in turn can create a poor user experience and
 > > >> occasional
 > > >> inconsistency  in cloudstack db.
 > > >>
 > > >> This is especially painful in large environments where the user
has
 > > >> thousands of nodes and there is a continuous patching that
happens
 > > >> around
 > > >> the clock - that requires migration of workload from one node to
 > > >> another.
 > > >>
 > > >> With that said - i've created a script that monitors the async
job
 > > >> queue
 > > >> for given MS and waits for it complete all jobs. More details
are
 > > >> posted
 > > >> below.
 > > >>
 > > >> I'd like to introduce "graceful-shutdown" into the
systemctl/service
 > of
 > > >> cloudstack-management service.
 > > >>
 > > >> The details of how it will work is below:
 > > >>
 > > >> Workflow for graceful shutdown:
 > > >> Using iptables/firewalld - block any connection attempts on
8080/8443
 > > >> (we
 > > >> can identify the ports dynamically)
 > > >> Identify the MSID for the node, using the proper msid - query
 > > >> async_job
 > > >> table for
 > > >> 1) any jobs that are still running (or job_status=“0”)
 > > >> 2) job_dispatcher not like “pseudoJobDispatcher"
 > > >> 3) job_init_msid=$my_ms_id
 > > >>
 > > >> Monitor this async_job table for 60 minutes - until all async
jobs for
 > > >> MSID
 > > >> are done, then proceed with shutdown
 > > >>  If failed for any reason or terminated, catch the exit via trap
 > > >> command
 > > >> and unblock the 8080/8443
 > > >>
 > > >> Comments are welcome
 > > >>
 > > >> Regards,
 > > >> ilya
 > > >>
 > > >>
 > > >>
 > > >>
 > > >> --
 > > >> Rafael Weingärtner
 > > >>
 > > >>
 > > >>
 > > >>
 > > >>
 > > >> --
 > > >> Rafael Weingärtner
 > > >>
 > >
 >
 >
 >
 > --
 >
 > Andrija Panić
 >







--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Host KVM Installation documentation

[Ron Wheeler]

I would like to work with someone who knows the truth about these issues.
Having someone who is not a committer working on the doc team helps a 
lot so that insider knowledge is not assumed to be widely known.


The accuracy of the documentation is not that bad but in programming, 
you can not have an "almost correct" product.

The documentation is one of the big barriers to entry.

Besides being wrong or outdated which makes it hard to use, it also 
projects an image of low quality and sloppy craftsmanship.


Using iptables in a CentOS7 environment just says that your product is 
dated and not keeping up with modern thinking.


$ iptables -I INPUT -p tcp -m tcp --dport 22 -j ACCEPT
should be
firewall-cmd --zone=public --add-port=22 --permanent
or, even better,
firewalld-cmd --zone=public --add-service=sshd --permanent

Much clearer that the rather obscure iptables statement which is cryptic 
to say the least.


It is not hard to fix the docs to use Firewalld.

The current installation does not suggest removing Firewalld so I gather 
that Cloudstack runs just fine with Firewalld.

The problem appears to just exist in the docs.

Ron

On 15/04/2018 7:12 AM, Parth Patel wrote:

Hi Ron,

Thanks for identifying this pressing issues. Many of my friends to whom I
have recommended to use Cloudstack (at UG level) say that it the docs are
mostly using CentOS 6's commands for RHEL/CentOS and that many a times they
have ran into issues with the documentation. What I do for host KVM
installation is stop and disable the firewalld, and then install
iptables-services package in CentOS 7. I think Cloudstack regulates the
firewall using iptables, so firewalld support would have to change the way
ACS manages network. I have personally prepared a host KVM installation
document (almost like quick install guide) which includes the changes or
deviations you need to do from the official documentation. If ACS community
needs help in documentation work, I can help as I have few months until the
start of my masters.

Your all other mails too, are relevant. I had a tough time figuring out and
explaining each concept to my colleagues during my internship at a company
as most of the ACS documentation is dated and is no longer relevant. I was
thinking to implement a ACS plugin, but as there were no sufficient docs
available I gave up on it. I don't want anyone to feel the same despair I
experienced if they wanted to extend ACS and add to the ACS community. I
have by far loved ACS more than OpenStack and would certainly love to
contribute to it.

Regards,
Parth Patel

On Sun, 15 Apr 2018 at 10:09 Ron Wheeler <rwhee...@artifact-software.com>
wrote:


http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/4.11/hypervisor/kvm.html

I am surprised to see that RedHat is not supported/recommended.

What about Atomic? CoreOS?

*Homogeneous CPUs*

"All hosts within a cluster must be homogenous. The CPUs must be of the
same type, count, and feature flags"
This appears to be an attempt to add some flesh to the definition of
homogeneous.
   What does type mean - AMD vs Intel? Can you really not use an Athlon
in the same cluster as a Phenom?

Count of what? CPUs?

Surely not all feature flags matter?

What is the real restriction?

When you deploy CloudStack, the hypervisor host must not have any VMs
already running. These will be destroy by CloudStack

Might be better expressed as
When you deploy CloudStack, any VMs already running on the hypervisor
host will be destroyed by CloudStack.

*Configure CPU model for KVM guest (Optional)*

By default, the CPU model of KVM instance is likely QEMU Virtual CPU
version x.x.x with least CPU features exposed.

likely??? What does this mean?

*CentOS 7 uses Firewalld**
*

The section on opening ports in the firewall uses iptables which is no
longer used in CentOS 7*
*

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102 <(866)%20970-2435>




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Host KVM Installation documentation

[Ron Wheeler]

http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/4.11/hypervisor/kvm.html

I am surprised to see that RedHat is not supported/recommended.

What about Atomic? CoreOS?

*Homogeneous CPUs*

"All hosts within a cluster must be homogenous. The CPUs must be of the 
same type, count, and feature flags"
This appears to be an attempt to add some flesh to the definition of 
homogeneous.
 What does type mean - AMD vs Intel? Can you really not use an Athlon 
in the same cluster as a Phenom?


Count of what? CPUs?

Surely not all feature flags matter?

What is the real restriction?

When you deploy CloudStack, the hypervisor host must not have any VMs 
already running. These will be destroy by CloudStack


Might be better expressed as
When you deploy CloudStack, any VMs already running on the hypervisor 
host will be destroyed by CloudStack.


*Configure CPU model for KVM guest (Optional)*

By default, the CPU model of KVM instance is likely QEMU Virtual CPU 
version x.x.x with least CPU features exposed.


likely??? What does this mean?

*CentOS 7 uses Firewalld**
*

The section on opening ports in the firewall uses iptables which is no 
longer used in CentOS 7*

*

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Welcome to CloudStack Documentation

[Ron Wheeler]

http://docs.cloudstack.apache.org/en/latest/index.html

The main menu on the left does not match the links in the text. It is 
full of seemingly unrelated documentation that discusses plug-ins 
programming and other specific topics that should only be visible at 
lower level of the docs.


This is also reflected in the menu at the top.

There is probably do much detail on the Integration Guides, the Advanced 
Networking Guides and the Developers Guide.
The top level with a link to the guide is sufficient for an introduction 
to Cloudstack.
These details also add maintenance overhead to keep this page in sync 
with the details of the specific manuals/articles.


Ron
*
*

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Documentation issues

[Ron Wheeler]

There are some simple problems with the documentation.
Some of these have been raised in the past but never fixed.

http://docs.cloudstack.apache.org/en/latest/concepts.html  is the first 
technical page that a new user will read.


*Loose text.*

At the top of the page under Concepts and Terminology there is a 
sentence that looks out of place.

"Primary storage is associated with a cluster"

*DIAGRAMS too simple and possibly wrong
*

The diagrams for Zones, Pods,Clusters should show at least 2 of the next 
lower level. The diagram for Regions looks much clearer as it show 3 
zones that make up the Region. The Pod diagram looks like the Primary 
storage is inside the Cluster which is different from what the text 
says. "A pod consists of one or more clusters of hosts and one or more 
primary storage servers"


*Clusters must have identical hardware*

The text says "The hosts in a cluster all have identical hardware, run 
the same hypervisor, are on the same subnet, and access the same shared 
primary storage." Is it true that the hardware must be "identical".That 
seems to an overstatement of the requirement.


*Redundant t**ext**in Cluster*

This sentence should be removed. It is clear from the whole discussion 
of the hierarchy.
"A cluster is the fourth-largest organizational unit within a CloudStack 
deployment. Clusters are contained within pods, and pods are contained 
within zones."


*Cluster Size*
" Size of the cluster is limited by the underlying hypervisor, although 
the CloudStack recommends less in most cases; see Best Practices."


What doe this actually mean? Is it true? Would an example make it clearer?
The hyperlink to Best Practices is missing.

*Host question*

The description says

 * May reside in multiple data centers across different geographic location

This contradicts previous statements that hosts exist inside clusters 
which are inside pods and zones which can only be in one datacenter.
This section also says that host in a cluster must be homogeneous which 
is different from identical but in no place is either identical or 
homogeneous ever defined and these are not commonly used in Computer 
Science with the definitions which I think are meant here.

*
**Primary Storage section contradicts Pod definitions and the entire 
previous hierachy*
The Pod section says that a pod consists of clusters and primary 
storage.  This section says that Primary storage is "associated" with a 
cluster not a pod.
It then goes on to recommend that Primary storage should be at the Zone 
level.
 Can someone make up a consistent definition of the relationship of 
Primary Storage to the rest of the structures and fix the diagrams to 
match the actual reality.


*Redundant Network Traffic Type definitions*
Not sure why the definitions are associated with both Basic and Advanced 
Network Traffic Types. The definitions appear to be the same and the 
fact that they appear twice is confusing.


*Basic Zone Network Traffic Type only requires Guest Network**
*The description of Basic Zone Network configuration says that you only 
need to define a Guest network. It makes no comments about the other 
traffic types.


*Accounts and Customers never defined*
In the discussion about Advanced Zone Guest IP Addresses, the concept of 
Accounts is used with no definition of what accounts.
There is also a mention of "Customers" without any description of what 
"Customers" means in a Cloudstack context.

*
**General Comment on exceptions
*My personal view is that there are too many references to specific 
product exceptions. These add too many confusing and conflicting**ideas 
for an introductory article. This is supposed to be  an introduction to 
the concepts and terminology that will be used in the rest of the 
documentation.*

*

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: cloudstack Wikipedia page

[Ron Wheeler]

The edit has been undone already.

There could be a better section on Key Features.
Perhaps a short paragraph outlining:
- what it is good for,
- what it competes with and
- why it needs to exist at all.

Is the other info accurate?

Is the user list up to date?

Ron

On 09/01/2018 5:21 AM, Giles Sirett wrote:

Somebody has made an edit to the cloudstack wikipedia entry

https://en.wikipedia.org/w/index.php?diff=819108440=815849996

In essence, they have changed the start of the history section to give a 
history of the cloud.com domain name. I do not think that is either relevant or 
appropriate to the history of cloudstack itself

Has anybody here got experience in editing on Wikipedia and able to 
object/change this edit ?

I'm happy to take this task on, but have no experience in the process, 
policies, etc


Kind regards
Giles


giles.sir...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
   
  



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Committee to Sort through CCC Presentation Submissions

[Ron Wheeler]

By the time you go through one and write up a commentary, you have used 
quite a bit of your discretionary time.

How many days are in the review period?

How many reviewers have volunteered?

I would hope that key organizers of the conference are only reviewing 
finalists where the author has already done a revision to address the 
reviewers comments and the reviewers have given it a passing grade.


How many presentations are going to be given?
Are there any "reserved" slots for presentations that will be given on 
behalf of the PMC as official project reports such as a roadmap or 
project overview?


Ron

On 05/04/2018 9:21 PM, Will Stevens wrote:
I need to get through a couple reviews to figure out the commitment. I 
have been a bit slammed at the moment.


On Thu, Apr 5, 2018, 9:19 PM Tutkowski, Mike, 
<mike.tutkow...@netapp.com <mailto:mike.tutkow...@netapp.com>> wrote:


Will – What do you think? With only 26 presentations, do you think
it would be reasonable to just ask each reviewer to review each
one? One time that I was on one of these panels a couple years
ago, we each reviewed the roughly dozen presentations that were
submitted. Of course, people may not be able to spend that amount
of time on this.

> On Apr 5, 2018, at 7:14 PM, Ron Wheeler
<rwhee...@artifact-software.com
<mailto:rwhee...@artifact-software.com>> wrote:
>
> We still need to manage the review process and make sure that it
is adequately staffed.
>
> The allocation of presentations to reviewers has to be managed
to be sure that the reviewers have the support that they need to
do a proper review and that the reviews get done.
>
> Ron
>
>
>> On 05/04/2018 11:45 AM, Tutkowski, Mike wrote:
>> Perfect…then, unless anyone has other opinions they’d like to
share on the topic, let’s follow that approach.
>>
>> On 4/5/18, 9:43 AM, "Rafael Weingärtner"
<rafaelweingart...@gmail.com <mailto:rafaelweingart...@gmail.com>>
wrote:
>>
>>     That is exactly it.
>>          On Thu, Apr 5, 2018 at 12:37 PM, Tutkowski, Mike
<mike.tutkow...@netapp.com <mailto:mike.tutkow...@netapp.com>>
>>     wrote:
>>          > Hi Rafael,
>>     >
>>     > I think as long as we (the CloudStack Community) have the
final say on how
>>     > we fill our allotted slots in the CloudStack track of
ApacheCon in
>>     > Montreal, then it’s perfectly fine for us to leverage
Apache’s normal
>>     > review process to gather all the feedback from the larger
Apache Community.
>>     >
>>     > As you say, we could wait for the feedback to come in via
that mechanism
>>     > and then, as per Will’s earlier comments, we could
advertise on our users@
>>     > and dev@ mailing lists when we plan to get together for a
call and make
>>     > final decisions on the CFP.
>>     >
>>     > Is that, in fact, what you were thinking, Rafael?
>>     >
>>     > Talk to you soon,
>>     > Mike
>>     >
>>     > On 4/4/18, 2:58 PM, "Rafael Weingärtner"
<rafaelweingart...@gmail.com <mailto:rafaelweingart...@gmail.com>>
>>     > wrote:
>>     >
>>     >     I think everybody that “raised their hands here”
already signed up to
>>     >     review.
>>     >
>>     >     Mike, what about if we only gathered the reviews from
Apache main
>>     > review
>>     >     system, and then we use that to decide which
presentations will get in
>>     >     CloudStack tracks? Then, we reduce the work on our
side (we also remove
>>     >     bias…). I do believe that the review from other peers
from Apache
>>     > community
>>     >     (even the one outside from our small community) will
be fair and
>>     > technical
>>     >     (meaning, without passion and or favoritism).
>>     >
>>     >     Having said that, I think we only need a small group
of PMCs to gather
>>     > the
>>     >     results and out of the best ranked proposals, we pick
the ones to our
>>     >     tracks.
>>     >
>>     >     What do you (Mike) and others think?
>>     >
>>     >
>>     >     On Tue, Apr 3, 2018 at 5:07 PM, Tutkowski, Mike <
>>     > mike.tutkow...@netapp.com <mailto:mike.tu

Re: Committee to Sort through CCC Presentation Submissions

[Ron Wheeler]

We still need to manage the review process and make sure that it is 
adequately staffed.


The allocation of presentations to reviewers has to be managed to be 
sure that the reviewers have the support that they need to do a proper 
review and that the reviews get done.


Ron


On 05/04/2018 11:45 AM, Tutkowski, Mike wrote:

Perfect…then, unless anyone has other opinions they’d like to share on the 
topic, let’s follow that approach.

On 4/5/18, 9:43 AM, "Rafael Weingärtner" <rafaelweingart...@gmail.com> wrote:

 That is exactly it.
 
 On Thu, Apr 5, 2018 at 12:37 PM, Tutkowski, Mike <mike.tutkow...@netapp.com>

 wrote:
 
 > Hi Rafael,

 >
 > I think as long as we (the CloudStack Community) have the final say on 
how
 > we fill our allotted slots in the CloudStack track of ApacheCon in
 > Montreal, then it’s perfectly fine for us to leverage Apache’s normal
 > review process to gather all the feedback from the larger Apache 
Community.
 >
 > As you say, we could wait for the feedback to come in via that mechanism
 > and then, as per Will’s earlier comments, we could advertise on our 
users@
 > and dev@ mailing lists when we plan to get together for a call and make
 > final decisions on the CFP.
 >
 > Is that, in fact, what you were thinking, Rafael?
 >
 > Talk to you soon,
 > Mike
 >
 > On 4/4/18, 2:58 PM, "Rafael Weingärtner" <rafaelweingart...@gmail.com>
 > wrote:
 >
 > I think everybody that “raised their hands here” already signed up to
 > review.
 >
 > Mike, what about if we only gathered the reviews from Apache main
 > review
 > system, and then we use that to decide which presentations will get 
in
 > CloudStack tracks? Then, we reduce the work on our side (we also 
remove
 > bias…). I do believe that the review from other peers from Apache
 > community
 > (even the one outside from our small community) will be fair and
 > technical
 > (meaning, without passion and or favoritism).
 >
 > Having said that, I think we only need a small group of PMCs to 
gather
 > the
 > results and out of the best ranked proposals, we pick the ones to our
 > tracks.
 >
 > What do you (Mike) and others think?
 >
 >
 > On Tue, Apr 3, 2018 at 5:07 PM, Tutkowski, Mike <
 > mike.tutkow...@netapp.com>
 > wrote:
 >
 > > Hi Ron,
 > >
 > > I don’t actually have insight into how many people have currently
 > signed
 > > up online to be CFP reviewers for ApacheCon. At present, I’m only
 > aware of
 > > those who have responded to this e-mail chain.
 > >
 > > We should be able to find out more in the coming weeks. We’re still
 > quite
 > > early in the process.
 > >
 > > Thanks for your feedback,
 > > Mike
 > >
 > > On 4/1/18, 9:18 AM, "Ron Wheeler" <rwhee...@artifact-software.com>
 > wrote:
 > >
 > > How many people have signed up to be reviewers?
 > >
 > > I don't think that scheduling is part of the review process and
 > that
 > > can
 > > be done by the person/team "organizing" ApacheCon on behalf of
 > the PMC.
 > >
 > > To me review is looking at content for
 > > - relevance
 > > - quality of the presentations (suggest fixes to content,
 > English,
 > > graphics, etc.)
 > > This should result in a consensus score
 > > - Perfect - ready for prime time
 > > - Needs minor changes as documented by the reviewers
 > > - Great topic but needs more work - perhaps a reviewer could
 > volunteer
 > > to work with the presenter to get it ready if chosen
 > > - Not recommended for topic or content reasons
 > >
 > > The reviewers could also make non-binding recommendations about
 > the
 > > balance between topics - marketing(why Cloudstack),
 > > Operations/implementation, Technical details, Roadmap, etc.
 > based on
 > > what they have seen.
 > >
 > > This should be used by the organizers to make the choices and
 > organize
 > > the program.
 > > The organizers have the final s

Re: Committee to Sort through CCC Presentation Submissions

[Ron Wheeler]

How many people have signed up to be reviewers?

I don't think that scheduling is part of the review process and that can 
be done by the person/team "organizing" ApacheCon on behalf of the PMC.


To me review is looking at content for
- relevance
- quality of the presentations (suggest fixes to content, English, 
graphics, etc.)

This should result in a consensus score
- Perfect - ready for prime time
- Needs minor changes as documented by the reviewers
- Great topic but needs more work - perhaps a reviewer could volunteer 
to work with the presenter to get it ready if chosen

- Not recommended for topic or content reasons

The reviewers could also make non-binding recommendations about the 
balance between topics - marketing(why Cloudstack), 
Operations/implementation, Technical details, Roadmap, etc. based on 
what they have seen.


This should be used by the organizers to make the choices and organize 
the program.
The organizers have the final say on the choice of presentations and 
schedule


Reviewers are there to help the process not control it.

I would be worried that you do not have enough reviewers rather than too 
many.

Then the work falls on the PMC and organizers.

When planning meetings, I would recommend that you clearly separate the 
roles and only invite the reviewers to the meetings about review. Get 
the list of presentation to present to the reviewers and decide if there 
are any instructions that you want to give to reviewers.
I would recommend that you keep the organizing group small. Membership 
should be set by the PMC and should be people that are committed to the 
ApacheCon project and have the time. The committee can request help for 
specific tasks from others in the community who are not on the committee.


I would also recommend that organizers do not do reviews. They should 
read the finalists but if they do reviews, there may be a suggestion of 
favouring presentations that they reviewed. It also ensures that the 
organizers are not getting heat from rejected presenters - "it is the 
reviewers fault you did not get selected".


My advice is to get as many reviewers as you can so that no one is 
essential and each reviewer has a limited number of presentations to 
review but each presentation gets reviewed by multiple people. Also bear 
in mind that not all reviewers have the same ability to review each 
presentation.
Reviews should be anonymous and only the summary comments given to the 
presenter. Reviewers of a presentation should be able to discuss the 
presentation during the review to make sure that reviewers do not feel 
isolated or get lost when they hit content that they don't understand fully.




Ron


On 01/04/2018 12:20 AM, Tutkowski, Mike wrote:

Thanks for the feedback, Will!

I agree with the approach you outlined.

Thanks for being so involved in the process! Let’s chat with Giles once he’s 
back to see if we can get your questions answered.


On Mar 31, 2018, at 10:14 PM, Will Stevens <wstev...@cloudops.com> wrote:

In the past the committee was chosen as a relatively small group in order
to make it easier to manage feedback.  In order to make it fair to everyone
in the community, I would suggest that instead of doing it with a small
group, we do it out in the open on a scheduled call.

We will have to get a list of the talks that are CloudStack specific from
ApacheCon, but that should be possible.

Once we have the talks selected, then a smaller number of us can work on
setting up the actual ordering and the details.

I have been quite involved so far.  Giles and I have been organizing the
sponsors, website and dealing with ApacheCon so far.  Obviously, Mike is
also working on this as well.

I think we are headed in the right direction on this.

Cheers,

Will

On Mar 31, 2018 11:49 PM, "Tutkowski, Mike" <mike.tutkow...@netapp.com>
wrote:

Hi Ron,

I am definitely open to working this however makes the most sense.

It looks like Will’s e-mail indicates that the process I suggested has been
followed in the past (which is how I recall, as well).

Let’s make sure I understood Will correctly.

Will – Are you, in fact, indicating that what I was suggesting is how we
have reviewed the CFP in the past? If so, are you able to address Ron’s
concerns?

Also, Will – I am not sure about a hackathon. Let’s chat with Giles once
he’s back from vacation since he’s been the most involved with organizing
the CloudStack track within ApacheCon.

Thanks!

Mike


On 3/31/18, 9:00 PM, "Ron Wheeler" <rwhee...@artifact-software.com> wrote:

I am not sure about your concern in that case.
I am not sure why people not interested in Cloudstack would volunteer as
reviewers and want to pick bad presentations.

I would be more worried that there are not enough good presentations
proposed rather than some meritorious presentation will get rejected due
to "outsiders" voting it down in favou

Re: Committee to Sort through CCC Presentation Submissions

[Ron Wheeler]

I am not sure about your concern in that case.
I am not sure why people not interested in Cloudstack would volunteer as 
reviewers and want to pick bad presentations.


I would be more worried that there are not enough good presentations 
proposed rather than some meritorious presentation will get rejected due 
to "outsiders" voting it down in favour of less useful presentations.


It may be tricky to get balance if that means taking "bad" proposals 
that can not be fixed that cover topics that are in areas that are not 
otherwise covered at the expense of great presentations that are in 
areas with many choices.


We should wait to see how many presentations have to be rejected and the 
number of reviewers before getting too exercised over the loyalty of 
reviewers.


Getting more reviewers is likely the most effective way to see that a 
wider range of topics is covered.


Ron

On 31/03/2018 7:15 PM, Tutkowski, Mike wrote:

Hi Ron,

 From what I understand, the CloudStack proposals will be mixed in with all of 
the ApacheCon proposals.

In the past when I’ve participated in these CloudStack panels to review 
proposals, we had to compare each proposal against the others to arrive at a 
balance of topics (i.e. not all networking focused, not all XenServer focused, 
etc.) and to suggest improvements for proposals that we did not accept for 
other reasons.

 From what I understand (but Giles can comment further on this), we have a 
track at ApacheCon and will need to fill it with X number of presentations. To 
do this, it seems like a CloudStack-focused panel would be a good approach, but 
I am definitely open to another approach. We don’t want to exclude anyone (in 
or out of the CloudStack Community) who might like to provide input. Anyone who 
is interested would, of course, be free to join us in combing through the 
proposals.

We don’t need to get started on this right away. The CFP just closed yesterday. 
Let’s wait for feedback from Giles (who is currently on vacation) and go from 
there.

Thanks!
Mike

On 3/31/18, 6:59 AM, "Ron Wheeler" <rwhee...@artifact-software.com> wrote:

 Is this a real concern?
 Why would a large number of Apache contributors who are not interested
 in Cloudstack (enough to outvote those "part of the Cloudstack
 community") get involved as reviewers
 
 Reviewing involves some commitment of time so I am hard pressed to guess

 why some Apache contributor would volunteer to do the work in order to
 veto a presentation that they have not yet seen or have no interest in
 seeing.
 
 Are we guaranteed a fixed number of hours of presentations or is the

 review process part of the allocation of overall time?
 
 On what basis can some group veto a presentation?

 That would seem to be a very strong action and I would hope that it
 requires a strong reason.
 
 OTOH if a large??? number of Apache contributors (regardless of their

 affiliation) say that a presentation has serious issues or very limited
 interest, that would seem to be a red flag that the presentation
 requires improvement or needs to be dropped in favour of another
 Cloudstack presentation, if it can not be fixed.
 
 We should also be aware that this is an opportunity to "market"

 Cloudstack to the broader Apache community.
 Outside reviewers might have valuable input into how presentations can
 attract new adopters or be clearer to the broader DevOps community.
 We also need to remember that we do have an active community and other
 opportunities during the year to present presentations that do not get
 selected for this conference.
 
 If their is a real fear that a lot of "outsiders" are going to disrupt

 the review process, a more reasonable response would seem to be to get
 more reviewers from the community.
 
 I have volunteered already.
 
 Ron
 
 On 30/03/2018 11:11 PM, Tutkowski, Mike wrote:

 > Hi Rafael,
 >
 > It’s a little bit tricky in our particular situation. Allow me to 
explain:
 >
 > As you are likely aware, the CloudStack Collaboration Conference will be 
held as a track in the larger ApacheCon conference in Montreal this coming 
September.
 >
 > It is true, as you say, that anyone who wishes to do so can contribute 
to reviewing the CFP for ApacheCon.
 >
 > What is a bit of a concern, however, is that we might get certain 
CloudStack CFP proposals vetoed by people who are not, per se, a part of our 
community.
 >
 > That being the case, I have contacted the organizers for ApacheCon to 
see if there is some way we can section off the CloudStack CFP from the larger 
ApacheCon CFP for review purposes.
 >
 > Assuming we can do this, the panel that I am proposing here would handle 
t

Re: Committee to Sort through CCC Presentation Submissions

[Ron Wheeler]

Is this a real concern?
Why would a large number of Apache contributors who are not interested 
in Cloudstack (enough to outvote those "part of the Cloudstack 
community") get involved as reviewers


Reviewing involves some commitment of time so I am hard pressed to guess 
why some Apache contributor would volunteer to do the work in order to 
veto a presentation that they have not yet seen or have no interest in 
seeing.


Are we guaranteed a fixed number of hours of presentations or is the 
review process part of the allocation of overall time?


On what basis can some group veto a presentation?
That would seem to be a very strong action and I would hope that it 
requires a strong reason.


OTOH if a large??? number of Apache contributors (regardless of their 
affiliation) say that a presentation has serious issues or very limited 
interest, that would seem to be a red flag that the presentation 
requires improvement or needs to be dropped in favour of another 
Cloudstack presentation, if it can not be fixed.


We should also be aware that this is an opportunity to "market" 
Cloudstack to the broader Apache community.
Outside reviewers might have valuable input into how presentations can 
attract new adopters or be clearer to the broader DevOps community.
We also need to remember that we do have an active community and other 
opportunities during the year to present presentations that do not get 
selected for this conference.


If their is a real fear that a lot of "outsiders" are going to disrupt 
the review process, a more reasonable response would seem to be to get 
more reviewers from the community.


I have volunteered already.

Ron

On 30/03/2018 11:11 PM, Tutkowski, Mike wrote:

Hi Rafael,

It’s a little bit tricky in our particular situation. Allow me to explain:

As you are likely aware, the CloudStack Collaboration Conference will be held 
as a track in the larger ApacheCon conference in Montreal this coming September.

It is true, as you say, that anyone who wishes to do so can contribute to 
reviewing the CFP for ApacheCon.

What is a bit of a concern, however, is that we might get certain CloudStack 
CFP proposals vetoed by people who are not, per se, a part of our community.

That being the case, I have contacted the organizers for ApacheCon to see if 
there is some way we can section off the CloudStack CFP from the larger 
ApacheCon CFP for review purposes.

Assuming we can do this, the panel that I am proposing here would handle this 
review task.

I hope that helps clarify the situation.

Thanks!
Mike

On 3/30/18, 8:38 AM, "Rafael Weingärtner" <rafaelweingart...@gmail.com> wrote:

 Are we going to have a separated review process?
 
 I thought anybody could go here [1] and apply for a reviewer position and

 start reviewing. Well, that is what I did. I have already reviewed some
 CloudStack proposals (of course I did not review mines). After asking to
 review presentations, Rich has giving me access to the system. I thought
 everybody interest in helping was going to do the same.
 
 [1] https://cfp.apachecon.com/conference.html?apachecon-north-america-2018
 
 
 On Wed, Mar 28, 2018 at 4:05 AM, Swen - swen.io <m...@swen.io> wrote:
 
 > Hi Mike,

 >
 > congrats!
 >
 > I can help sort through presentations.
 >
 > Best regards,
 > Swen
 >
 > -Ursprüngliche Nachricht-
 > Von: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com]
 > Gesendet: Dienstag, 27. März 2018 21:40
 > An: dev@cloudstack.apache.org; us...@cloudstack.apache.org
 > Betreff: Committee to Sort through CCC Presentation Submissions
 >
 > Hi everyone,
 >
 > As you may be aware, this coming September in Montreal, the CloudStack
 > Community will be hosting the CloudStack Collaboration Conference:
 >
 > http://ca.cloudstackcollab.org/
 >
 > Even though the event is six months away, we are on a tight schedule with
 > regards to the Call For Participation (CFP):
 >
 > https://www.apachecon.com/acna18/schedule.html
 >
 > If you are interested in submitting a talk, please do so before March 
30th.
 >
 > That being said, as usual, we will have need of a small committee to sort
 > through these presentation submissions.
 >
 > If you are interested in helping out in this process, please reply to 
this
 > message.
 >
 > Thanks!
 > Mike
 >
 >
 >
 
 
 --

 Rafael Weingärtner
 



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Welcoming Mike as the new Apache CloudStack VP

[Ron Wheeler]

Congratulations Mike!

Ron
On 26/03/2018 10:11 AM, Wido den Hollander wrote:

Hi all,

It's been a great pleasure working with the CloudStack project as the
ACS VP over the past year.

A big thank you from my side for everybody involved with the project in
the last year.

Hereby I would like to announce that Mike Tutkowski has been elected to
replace me as the Apache Cloudstack VP in our annual VP rotation.

Mike has a long history with the project and I am are happy welcome him
as the new VP for CloudStack.

Welcome Mike!

Thanks,

Wido



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Ron Wheeler]

I am not sure that it makes any difference about which tracking system 
is chosen.
Google will find the issues related to my problem (and a million that 
somehow have a vague connection to the words that I used).
Developers will be able to find the issue tracking system regardless of 
where it is hosted.
My IDE (Eclipse STS) automatically shows the issues for the issue repos 
that I configure.


I thought that the discussion was about approving PRs with no issues.

On 14/03/2018 10:42 AM, Will Stevens wrote:
Ron, for this I think we would be using Github Issues if we were not 
using Jira. Essentially all of the project information would be found 
in the same place rather than the user having to discover all the 
different systems that we use to track things and then try to make 
sense of it.


*Will Stevens*
Chief Technology Officer
c514.826.0190

<https://goo.gl/NYZ8KK>

On Wed, Mar 14, 2018 at 10:04 AM, Ron Wheeler 
<rwhee...@artifact-software.com 
<mailto:rwhee...@artifact-software.com>> wrote:


I am not a Cloudstack developer and generally have no interest in PRs.
If I have a problem, I want to search the Jira
 - What was the symptom  - is it related to the problem that I am
having - may not be exactly the same but might be related
 - How was it reproduced - is this related to what I am trying to
do - can I change my configuration decisions to avoid the issue
 - What remedies were considered - could any of these have side
effects that could account for my issue
 - Why was the specific fix chosen - is my problem an edge case
that was created or ignored by this decision
 - Is there any discussion that could help me decide if my problem
is related.
 - Is there any info in the discussion that educates me to a point
where I know what tests to run to refine my understanding my issue.
 - What are the side-effects of the fix.
 - Was it back ported
 - What issues were discovered during backporting

I am not sure that a PR will be much use to a sysadmin if the
issue is non-trivial.
If we ask people creating PRs to add all the things that a
sysadmin requires, PRs may get too difficult to make.

OTOH, I agree with Paul that PRs without Jira issues for doc
updates and corrections that do *not affect functionality* would
not make life too difficult and might encourage people to fix doc
problems, clean code and update libraries.

Ron


On 14/03/2018 7:25 AM, Paul Angus wrote:

Oh boy! Where to start

Ok, so wrt Rohit's original point, I'm a +1 for doc updates
and very trivial stuff a GOOD & COMPLETE title and summary in
a PR probably suffices.

Wrt Jira, for keeping track of *un*implemented changes and
*un*fixed bugs - I think that it (or something similar) is a
must.  Which shouldn't leave much to be honest.  As some point
a person has decided to make a code change or has found a bug,
right then the 'thing', by definition, falls into one of the
above categories.



Kind regards,

Paul Angus

paul.an...@shapeblue.com <mailto:paul.an...@shapeblue.com>
www.shapeblue.com <http://www.shapeblue.com>
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue


-Original Message-
From: Daan Hoogland <daan.hoogl...@gmail.com
<mailto:daan.hoogl...@gmail.com>>
Sent: 14 March 2018 10:05
To: dev <dev@cloudstack.apache.org
<mailto:dev@cloudstack.apache.org>>
Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

Let me add to the below that I do think a ticketing system is
a big help for keeping track of *un*implemented changes and
*un*fixed bugs.

On Wed, Mar 14, 2018 at 11:04 AM, Daan Hoogland
<daan.hoogl...@gmail.com <mailto:daan.hoogl...@gmail.com>>
wrote:

Boris, I hate to be strongly opinionated but I have to
violently
disagree with you on some things here;

On Wed, Mar 14, 2018 at 9:48 AM, Boris Stoyanov <
boris.stoya...@shapeblue.com
<mailto:boris.stoya...@shapeblue.com>> wrote:

Hi all,

I do understand your point as developers if you want
to fix something
just open the PR and not deal with any extra details
like JIRA
tickets and etc, but I must say that JIRA tickets are
quite often
looked up from users as they experience an issue.

​It is not more or less effort for users to look up github
PRs than
Jira tickets. They still need to be clever about search
terms and
still might miss out.
​

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Ron Wheeler]

lease

notes

perspective).  This is why the release notes can show

changes

that

only

have PRs and no Jira ticket.  At least my release notes

generator

is

built

that way.  I think Rohit has built a similar release

notes

generator,

so

I

can't speak to his version...

*Will Stevens*
Chief Technology Officer
c 514.826.0190

<https://goo.gl/NYZ8KK>

On Tue, Mar 13, 2018 at 6:42 AM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:


Marc, yes Jira tickets are used to register changes.

However,

what

Rohit

and others (including me) are noticing is that there

are

certain

types

of

changes (minor/bureaucracy) that do not require Jira

tickets.

The

issue

is

the wording “change”. What consist of a change that is

worth

mentioning

in

the release notes? Everything we do in a branch is a

change

towards a

release, but not everything is useful for

operators/administrators

to

see.

I would say that to fix bugs, introduce new features,

extend

existing

features, introduce a major change in the code such as

that

standard

maven

thing that you did, they all required Jira tickets to

track

the

discussion

and facilitate the management. On the other side of

the

spectrum,

we

have

things such as removing dead/unused code, opening a

new

version

(creating

the upgrade path that we still use for the DB), fix a

description

in

an

API

method, and so on. Moreover, the excessive use of Jira

tickets

leads

to

hundreds of Jira tickets that we do not know that

status

of.

We

have

quite

a big number of tickets opened that could be closed.

This

has

been

worse;

we are improving as time goes by.

I would say that to make this more transparent to

others

(especially

newcomers), we need to discuss it, then write it down

to

make

it

transparent the way we are working.

On Tue, Mar 13, 2018 at 6:59 AM, Marc-Aurèle Brothier

<

ma...@exoscale.ch

wrote:


That's a good idea, because people are more and more

used

to

only

create

PR

on github, and it would be helpful to be more

explanatory

on

the

way

we

work to push changes. I still think we should

encourage

the

use

of

the

github milestone as Rohit did with the 4.11.0 (
https://github.com/apache/clou

dstack/milestone/3?closed=1)

to

list

the

changes in the release notes with the help of the

labels to

tag

the

PRs

instead of relying on the jira ticket (it requires

to

have

another

login).

As far as I can remember, the JIRA tickets are used

to

list

the

changes

of

a release, but nothing else. Or am I missing

something?

Marc-Aurèle

On Tue, Mar 13, 2018 at 9:57 AM, Rohit Yadav <

rohit.ya...@shapeblue.com>

wrote:


All,


To make it easier for people to contribute changes

and

encourage

PR/contributions, should we relax the requirement

of a

JIRA

ticket

for

pull

requests that solve trivial/minor issues such as

doc

bugs,

build

fixes

etc?

A JIRA ticket may still be necessary for new

features

and

non-trivial

bugfixes or changes.


Another alternative could be to introduce a

CONTRIBUTING.md

[1]

that

explains the list of expected things to

contributors

when

they

send a

PR

(for example, a jira id, links to fs or other

resources,

a

short

summary

and long description, test results etc).


Thoughts?


[1] https://help.github.com/articl

es/setting-guidelines-

for-repository-contributors/


- Rohit

<https://cloudstack.apache.org>



rohit.ya...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N

4HSUK

@shapeblue







--
Rafael Weingärtner




--
Rafael Weingärtner




--
Daan




--
Rafael Weingärtner




--
Daan




--
Rafael Weingärtner




--
Daan




--
Rafael Weingärtner




--
Rafael Weingärtner





--
Daan






--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Releases in Progress

[Ron Wheeler]

Makes sense but we should try to get rid of inaccurate stuff and stuff 
that makes it look like the project is not maintained.


This is particularly and obviously true with pages that talk about 
"current" versions, roadmaps and outstanding issues.


The page in question was very explicit about version 4.6 being current 
and duplicated the ideas that were contained in a page about release 
policy that was not version specific. It did have some nice graphics 
that might be worth incorporating into  the other page.


The structure of the wiki needs a bit of thought and cleaning up. It 
needs to be looked at from a "marketing" point of view rather than a 
developer point of view. Development policies need to be included since 
they are important but they need to be written in a version-free point 
of view and need to be structured in a way that a first time visitor 
will have an easy way to find what they need and will find as many pages 
that paint a favourable view of the project as is possible without lying.


The details about version numbers and release policies are not top of 
mind with a person doing an evaluation of Cloudstack and its 
alternatives but is critical for developers.


Ron



On 05/02/2018 11:14 PM, Will Stevens wrote:
My point was simply that if it has good ranking already, we should 
update the page so we can put relevant information there so it can be 
easily found.  Just trying to leverage it in our favor is all.


*Will Stevens*
Chief Technology Officer
c514.826.0190

<https://goo.gl/NYZ8KK>

On Mon, Feb 5, 2018 at 10:34 PM, Ron Wheeler 
<rwhee...@artifact-software.com 
<mailto:rwhee...@artifact-software.com>> wrote:


SEO ranking is great but putting up stuff from 3 or 4 releases in
the past blows away all of the SEO benefit when someone actually
goes to the page.
The reader is left with the impression that the product is not
actively supported (actively developed but not supported)

I am not sure that SEO raking makes any difference when the number
of alternative search results is so small.
How many "products" will rank ahead of Cloudstack for
virtualization orchestration?

Is there a list of search keywords for which we want to get a high
ranking?
Who are the competitors and what keywords should they win?

Ron



On 05/02/2018 4:13 PM, Will Stevens wrote:

As a project, especially around the topic of 'releases', I
assume we should
leverage any SEO placement we can use.  I don't have specific
content I
think we should put there, but if it is well placed, it would
make sense
that we put some detail on the page.  We don't have to, but I
figured I
would mention it.

*Will Stevens*
Chief Technology Officer
c 514.826.0190 

<https://goo.gl/NYZ8KK>

On Mon, Feb 5, 2018 at 4:07 PM, Daan Hoogland
<daan.hoogl...@gmail.com <mailto:daan.hoogl...@gmail.com>>
wrote:

no one had made use of it since the RM for 4.4 (no who was
that again) We
can undelete if you wish. I copied the only worthwhile
page to the HOWTO
articles.

On Mon, Feb 5, 2018 at 10:02 PM, Will Stevens
<wstev...@cloudops.com <mailto:wstev...@cloudops.com>>
wrote:

Is there a reason we deleted it and didn't just update
it?  It would have
been good to take advantage of the SEO that page
already had working for

us

and just update the content to represent the latest
details.  No?

*Will Stevens*
Chief Technology Officer
c 514.826.0190 

<https://goo.gl/NYZ8KK>

On Mon, Feb 5, 2018 at 4:00 PM, Daan Hoogland
<daan.hoogl...@gmail.com <mailto:daan.hoogl...@gmail.com>>
        wrote:

deleted

On Fri, Feb 2, 2018 at 2:05 PM, Ron Wheeler

<rwheeler@artifact-software.

com>
wrote:


https://cwiki.apache.org/confluence/display/CLOUDSTACK/Relea

<https://cwiki.apache.org/confluence/display/CLOUDSTACK/Relea>
ses+in+Progress is old and needs to be update
to talk about ACS 4.10,
        4.11 and 4.12.

Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
<mailto:rwhee...@artifact-software.com>
skype: ronaldmwhe

Re: Releases in Progress

[Ron Wheeler]

SEO ranking is great but putting up stuff from 3 or 4 releases in the 
past blows away all of the SEO benefit when someone actually goes to the 
page.
The reader is left with the impression that the product is not actively 
supported (actively developed but not supported)


I am not sure that SEO raking makes any difference when the number of 
alternative search results is so small.
How many "products" will rank ahead of Cloudstack for virtualization 
orchestration?


Is there a list of search keywords for which we want to get a high ranking?
Who are the competitors and what keywords should they win?

Ron



On 05/02/2018 4:13 PM, Will Stevens wrote:

As a project, especially around the topic of 'releases', I assume we should
leverage any SEO placement we can use.  I don't have specific content I
think we should put there, but if it is well placed, it would make sense
that we put some detail on the page.  We don't have to, but I figured I
would mention it.

*Will Stevens*
Chief Technology Officer
c 514.826.0190

<https://goo.gl/NYZ8KK>

On Mon, Feb 5, 2018 at 4:07 PM, Daan Hoogland <daan.hoogl...@gmail.com>
wrote:


no one had made use of it since the RM for 4.4 (no who was that again) We
can undelete if you wish. I copied the only worthwhile page to the HOWTO
articles.

On Mon, Feb 5, 2018 at 10:02 PM, Will Stevens <wstev...@cloudops.com>
wrote:


Is there a reason we deleted it and didn't just update it?  It would have
been good to take advantage of the SEO that page already had working for

us

and just update the content to represent the latest details.  No?

*Will Stevens*
Chief Technology Officer
c 514.826.0190

<https://goo.gl/NYZ8KK>

On Mon, Feb 5, 2018 at 4:00 PM, Daan Hoogland <daan.hoogl...@gmail.com>
wrote:


deleted

On Fri, Feb 2, 2018 at 2:05 PM, Ron Wheeler

<rwheeler@artifact-software.

com>
wrote:


https://cwiki.apache.org/confluence/display/CLOUDSTACK/Relea
ses+in+Progress is old and needs to be update to talk about ACS 4.10,
4.11 and 4.12.

Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102




--
Daan




--
Daan




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Releases in Progress

[Ron Wheeler]

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases+in+Progress 
is old and needs to be update to talk about ACS 4.10, 4.11 and 4.12.


Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Clean wiki

[Ron Wheeler]

 If you search in Google with "cloudstack release schedule", top result is

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases which says

This page is outdated and will be updated. Please seethis page for our 
Release Principles for Apache CloudStack 4.6 and on 
<https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up>.


It dates back to 2015.

Can it be removed from public view ie deleted/archived?

Does it contain any info that is still useful that should be copied to 
another page or should the page be edited and renamed.



Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [PROPOSE] EOL for supported OSes & Hypervisors

[Ron Wheeler]

They would be locked into ACS version 11 if the team incorporated any 
dependency on new features from RHEL/CentOS 7 into an ACS version after 11.


I gather that this would give them full support until the beginning of 
2020 depending on when the support clock starts for ACS 11.


Would this allow them enough time to get a migration completed?

I suppose that they could find a vendor that would offer them a plan of 
extended ACS 11 support to apply security fixes to ACS 11 after it goes 
off official LTS support.


If testing on Centos 6 was dropped in the ACS 12 Release Plan without 
inclusion of any CentOS 7 dependencies into the actual code, they would 
have to do their own testing of RCs  for ACS 12 on CentOS 6  or pay a 
support team to do this testing and to modify any installation/upgrade 
scripts that will not run on CentOS 6.


So far we are up to 1 possible existing client where this is a problem.

I believe the other client using CentOS 6 did not actually have the 
CentOS 6 hosts managed by ACS.


Ron


On 22/01/2018 7:42 AM, Dag Sonstebo wrote:

Agree with Ron that new CloudStack users are unlikely to want to use 
RHEL/CentOS v6.x, however as Eric hinted at there will be existing CloudStack 
users using version 6 for a while still.

I am working with one company with 1000+ RHEL6 KVM hosts and no easy (or 
particularly clean) RHEL7 upgrade path – for them dropping RHEL6 support in 
2018 would be a major issue.

On the management side this should however be a lot less of an issue.

Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue

On 17/01/2018, 14:50, "Ron Wheeler" <rwhee...@artifact-software.com> wrote:

 It might also be helpful to know what version of ACS as well.
 Some indication of your plan/desire to upgrade ACS, hypervisor, or
 management server operating system might be helpful.
 There is a big difference between the situation where someone is running
 ACS 4.9x on CentOS 6 and wants to upgrade to ACS 4.12 while keeping
 CentOS 6 and another environment where the planned upgrade to ACS4.12
 will be done at the same time as an upgrade to CentOS 7.x.
 
 Is it fair to say that any proposed changes in this area will occur in

 4.12 at the earliest and will not likely occur before summer 2018?
 
 
 Ron
 
 
 On 17/01/2018 4:23 AM, Paul Angus wrote:

 > Thanks Eric,
 >
 > As you'll see from the intro email to this thread, the purpose here is 
to ensure that we don't strand a 'non-trivial' number of users by dropping support 
for any given hypervisor, or management server operating system.
 >
 > Hence the request to users to let the community know what they are 
using, so that a fact-based community consensus can be reached.
 >
 >
 > Kind regards,
 >
 > Paul Angus
 >
 > paul.an...@shapeblue.com
 > www.shapeblue.com
 > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
 > @shapeblue
 >
 >
 >
 >
 > -Original Message-
 > From: Eric Lee Green [mailto:eric.lee.gr...@gmail.com]
 > Sent: 16 January 2018 23:36
 > To: us...@cloudstack.apache.org
 > Subject: Re: [PROPOSE] EOL for supported OSes & Hypervisors
 >
 >> This is the type of discussion that I wanted to open - the argument
 >> that I see for earlier dropping of v6 is that - Between May 2018 and
 >> q2 2020 RHEL/CentOS 6.x will only receive security and mission
 >> critical updates, meanwhile packages on which we depend or may want to
 >> utilise in the future are been deprecated or not developed for v6.x
 > But this has always been the case for Centos 6.x. It is running antique 
versions of everything, and has been doing so for quite some time. It is, for 
example, running versions of Gnome and init that have been obsolete for years. 
Same deal with the version of MySQL that it comes with.
 >
 > The reality is that Centos 6.x guest support, at the very least, needs 
to be tested with each new version of Cloudstack until final EOL of Centos 6 in Q2 
2020. New versions of Cloudstack with new features not supported by Centos 6 (such 
as LVM support for KVM, which requires the LIO storage stack) can require Centos 7 
or later, but the last Cloudstack version that supports Centos 6.x as its server 
host should continue to receive bug fixes until Centos 6.x is EOL.
 >
 > Making someone's IT investment obsolete is a way to irrelevancy.
 > Cloudstack is already an also-ran in the cloud marketplace. Making 
someone's IT investment obsolete before the official EOL time for their IT 
investment is a good way to have a mass migration away from your technology.
 >
 > This doesn't particularly affect me since my Centos 6 virtualization 
hosts are not running Cloudstack and are going to b

Re: [PROPOSE] EOL for supported OSes & Hypervisors

[Ron Wheeler]

 wrote:

+1 I've updated the page with upcoming Ubuntu 18.04 LTS.


After 4.11, I think 4.12 (assuming releases by mid of 2018) should remove 
"declared" (they might still work with 4.12+ but in docs and by project we 
should officially support them) support for following:


a. Hypervisor:

XenServer - 6.2, 6.5,

KVM - CentOS6, RHEL6, Ubuntu12.04 (I think this is already removed,
packages don't work I think?)

vSphere/Vmware - 4.x, 5.0, 5.1, 5.5


b. Remove packaging for CentOS6.x, RHEL 6.x (the el6 packages), and Ubuntu 
12.04 (any non-systemd debian distro).


Thoughts, comments?



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [PROPOSE] EOL for supported OSes & Hypervisors

[Ron Wheeler]

I am having a hard time imagining why a new Cloudstack user would want 
to use CentOS 6.
I have not heard complaints from any forum about applications running on 
CentOS 6 that could not run on CentOS 7.


It does have an impact of DevOps but even there it is pretty minor and 
well documented and once one gets one's head around systemctl, 
journalctl and firewalld, it really is a lot better


As you pointed out, support for CentOS 7 is mandatory regardless of the 
decision on CentOS 6.
It will be a big black mark against CloudStack if the current 
RedHat/CentOS release is not supported 2.5 years after its release.


For existing Cloudstack users, is there a large risk that dropping 
official support for CentOS6 as a VM would result in a CentOS 6 VM not 
running after an upgrade to the latest Cloudstack?
Is there anyone in the community that absolutely can not upgrade? Would 
they take over the testing of CentOS 6 if official support was dropped?


Anyone using CentOS6 as a hypervisor will have to upgrade soon in any 
event and as you point out Cloudstack will soon be forced to move from 
CentOS 6 by dependencies dropping support for CentOS 6.


It would seem to make sense to declare an EOL date for support for 
CentOS 6 as a hypervisor as soon as possible so that system 
administrators are put on notice.


Ron



On 16/01/2018 12:58 PM, Paul Angus wrote:

Hi Eric,

This is the type of discussion that I wanted to open - the argument that I see 
for earlier dropping of v6 is that - Between May 2018 and q2 2020 RHEL/CentOS 
6.x will only receive security and mission critical updates, meanwhile packages 
on which we depend or may want to utilise in the future are been deprecated or 
not developed for v6.x
Also the testing and development burden on the CloudStack community increases 
as we try to maintain backward compatibility while including new versions.

Needing installation documentation for centos 7 is a great point, and something 
that we need to address regardless.


Does anyone else have a view, I'd really like to here from a wide range of 
people.

Kind regards,

Paul Angus

paul.an...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
   
  



-Original Message-
From: Eric Green [mailto:eric.lee.gr...@gmail.com]
Sent: 12 January 2018 17:24
To: us...@cloudstack.apache.org
Cc: dev@cloudstack.apache.org
Subject: Re: [PROPOSE] EOL for supported OSes & Hypervisors

Official EOL for Centos 6 / RHEL 6 as declared by Red Hat Software is 
11/30/2020. Jumping the gun a bit there, padme.

People on Centos 6 should certainly be working on a migration strategy right 
now, but the end is not here *yet*. Furthermore, the install documentation is 
still written for Centos 6 rather than Centos 7. That needs to be fixed before 
discontinuing support for Centos 6, eh?


On Jan 12, 2018, at 04:35, Rohit Yadav <rohit.ya...@shapeblue.com> wrote:

+1 I've updated the page with upcoming Ubuntu 18.04 LTS.


After 4.11, I think 4.12 (assuming releases by mid of 2018) should remove 
"declared" (they might still work with 4.12+ but in docs and by project we 
should officially support them) support for following:


a. Hypervisor:

XenServer - 6.2, 6.5,

KVM - CentOS6, RHEL6, Ubuntu12.04 (I think this is already removed, packages 
don't work I think?)

vSphere/Vmware - 4.x, 5.0, 5.1, 5.5


b. Remove packaging for CentOS6.x, RHEL 6.x (the el6 packages), and Ubuntu 
12.04 (any non-systemd debian distro).


Thoughts, comments?



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Which StringUtils to use?

[Ron Wheeler]

Certainly better to find the references and remove them if you can get 
that done in a single effort.


Just a technical question: Could one not just add the Warning to the 
constructor?

Might have to create a null (log warning only) constructor.

Ron

On 10/01/2018 3:58 PM, Daan Hoogland wrote:

We can add log messages to each of the methods in StringUtils but I do not
think that is a good way to go. Any method you touch you can reform or
remove anyhow.

On Wed, Jan 10, 2018 at 9:51 PM, Ron Wheeler <rwhee...@artifact-software.com

wrote:
Agreed about deprecation.
A logged WARNing would be detected during testing as well as at run-time.

Ron

On 10/01/2018 3:34 PM, Daan Hoogland wrote:

Ron, we could but that would only log during compile-time, not on runtime.
I am doing some analysis and commenting in Wido's ticket.

On Wed, Jan 10, 2018 at 9:23 PM, Ron Wheeler <rwheeler@artifact-software.
com> wrote:


Is it possible to mark it as deprecated and have it log a warning when
used?

Ron


On 10/01/2018 2:26 PM, Daan Hoogland wrote:


I think we could start with giving it an explicit non standard name like
CloudStackLocalStringUtils or something a little shorter. Making sure
that
we prefer for these types of utils to be imported from other projects.

On Wed, Jan 10, 2018 at 4:26 PM, Wido den Hollander <w...@widodh.nl>
wrote:



On 01/10/2018 01:09 PM, Rafael Weingärtner wrote:

Instead of creating a PR for that, we could do the bit by bit job

(hopefully one day we finish the job).
Every time we see a code using ACS's StringUtils, we check if it can be
replaced by Apache's one.


Yes, but that will slip from peoples attention and we will probably see

cases where people still use the old one by accident.

I've created a issue: https://issues.apache.org/jira
/browse/CLOUDSTACK-10225

I also started on some low hanging fruit as some methods in StringUtils
are not used or are very easy to replace.


Wido

On Wed, Jan 10, 2018 at 10:01 AM, Wido den Hollander <w...@widodh.nl>


wrote:


On 01/10/2018 12:01 PM, Daan Hoogland wrote:

I'd say remove as much functionality as we can from 'our' StringUtils
and


phase them out asap.


Yes, but such a PR would be invasive and would be difficult to merge
and


also break a lot of other code.

It's not easy since it will touch a lot, but I mean, a lot of files.

Our StringUtils was a very good solution, but the Apache one is
better I
think.

Wido


On Wed, Jan 10, 2018 at 11:59 AM, Wido den Hollander <w...@widodh.nl>

wrote:

Hi,

We have com.cloud.utils.StringUtils which has a few nice functions,

but
throughout the code I also see org.apache.commons.lang.StringUtils

They both provide about the same functionality, but which one do we
prefer?

I'd say org.apache.commons.lang.StringUtils as that allows us to
remove
our own StringUtils, but we could also have 'our' StringUtils simply
be a
wrapper around org.apache.commons.lang.StringUtils

Opinions?

Wido







--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102




--
Daan


--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102







--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Which StringUtils to use?

[Ron Wheeler]

Agreed about deprecation.
A logged WARNing would be detected during testing as well as at run-time.

Ron
On 10/01/2018 3:34 PM, Daan Hoogland wrote:
Ron, we could but that would only log during compile-time, not on 
runtime. I am doing some analysis and commenting in Wido's ticket.


On Wed, Jan 10, 2018 at 9:23 PM, Ron Wheeler 
<rwhee...@artifact-software.com 
<mailto:rwhee...@artifact-software.com>> wrote:


Is it possible to mark it as deprecated and have it log a warning
when used?

Ron


On 10/01/2018 2:26 PM, Daan Hoogland wrote:

I think we could start with giving it an explicit non standard
name like
CloudStackLocalStringUtils or something a little shorter.
Making sure that
we prefer for these types of utils to be imported from other
projects.

On Wed, Jan 10, 2018 at 4:26 PM, Wido den Hollander
<w...@widodh.nl <mailto:w...@widodh.nl>> wrote:


On 01/10/2018 01:09 PM, Rafael Weingärtner wrote:

Instead of creating a PR for that, we could do the bit
by bit job
(hopefully one day we finish the job).
Every time we see a code using ACS's StringUtils, we
check if it can be
replaced by Apache's one.


Yes, but that will slip from peoples attention and we will
probably see
cases where people still use the old one by accident.

I've created a issue: https://issues.apache.org/jira
/browse/CLOUDSTACK-10225

I also started on some low hanging fruit as some methods
in StringUtils
are not used or are very easy to replace.


Wido

On Wed, Jan 10, 2018 at 10:01 AM, Wido den Hollander
<w...@widodh.nl <mailto:w...@widodh.nl>>

wrote:


On 01/10/2018 12:01 PM, Daan Hoogland wrote:

I'd say remove as much functionality as we can
from 'our' StringUtils and

phase them out asap.


Yes, but such a PR would be invasive and would
be difficult to merge and

also break a lot of other code.

It's not easy since it will touch a lot, but I
mean, a lot of files.

Our StringUtils was a very good solution, but the
Apache one is better I
think.

Wido


On Wed, Jan 10, 2018 at 11:59 AM, Wido den
Hollander <w...@widodh.nl <mailto:w...@widodh.nl>>

wrote:

Hi,

We have com.cloud.utils.StringUtils which
has a few nice functions, but
throughout the code I also see
org.apache.commons.lang.StringUtils

They both provide about the same
functionality, but which one do we
prefer?

I'd say
org.apache.commons.lang.StringUtils as
that allows us to
remove
our own StringUtils, but we could also
have 'our' StringUtils simply
be a
wrapper around
org.apache.commons.lang.StringUtils

Opinions?

        Wido








-- 
Ron Wheeler

President
Artifact Software Inc
email: rwhee...@artifact-software.com
<mailto:rwhee...@artifact-software.com>
skype: ronaldmwheeler
    phone: 866-970-2435, ext 102




--
Daan



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: cloudstack Wikipedia page

[Ron Wheeler]

Can someone update the important technical sections  - Key Features, 
Supported Hypervisors and Bare Metal Hosts.

It looks like Cloudstack stopped being worked on in 2012.

Can these sections be replaced by a link to the correct CloudStack wiki 
pages so we do not have to keep updating this info?


The user list may also need updating or changed to a reference to to a 
page that is kept up to date.


I suspect that the history section captures too many details. There 
seems to be too much about the shift to Apache and whole process of 
incubation. Perhaps this process was very exciting and fresh when it was 
written but looking back from today, perhaps it is less important. 
Dropping one or 2 ideas and adding some more recent events might make sense


Is it true that Citrix has ceased involvement as it says?

Perhaps there are other companies that have made a significant 
investment in Cloudstack more recently that deserve mention.


Is it worth mentioning that there is an active community with specific 
reference to community meetings and events?


Ron

On 09/01/2018 5:58 AM, Daan Hoogland wrote:

just anonymously removed it, Giles

On Tue, Jan 9, 2018 at 11:21 AM, Giles Sirett <giles.sir...@shapeblue.com>
wrote:


Somebody has made an edit to the cloudstack wikipedia entry

https://en.wikipedia.org/w/index.php?diff=819108440=815849996

In essence, they have changed the start of the history section to give a
history of the cloud.com domain name. I do not think that is either
relevant or appropriate to the history of cloudstack itself

Has anybody here got experience in editing on Wikipedia and able to
object/change this edit ?

I'm happy to take this task on, but have no experience in the process,
policies, etc


Kind regards
Giles


giles.sir...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue








--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Which StringUtils to use?

[Ron Wheeler]

Is it possible to mark it as deprecated and have it log a warning when used?

Ron

On 10/01/2018 2:26 PM, Daan Hoogland wrote:

I think we could start with giving it an explicit non standard name like
CloudStackLocalStringUtils or something a little shorter. Making sure that
we prefer for these types of utils to be imported from other projects.

On Wed, Jan 10, 2018 at 4:26 PM, Wido den Hollander <w...@widodh.nl> wrote:



On 01/10/2018 01:09 PM, Rafael Weingärtner wrote:


Instead of creating a PR for that, we could do the bit by bit job
(hopefully one day we finish the job).
Every time we see a code using ACS's StringUtils, we check if it can be
replaced by Apache's one.



Yes, but that will slip from peoples attention and we will probably see
cases where people still use the old one by accident.

I've created a issue: https://issues.apache.org/jira
/browse/CLOUDSTACK-10225

I also started on some low hanging fruit as some methods in StringUtils
are not used or are very easy to replace.


Wido

On Wed, Jan 10, 2018 at 10:01 AM, Wido den Hollander <w...@widodh.nl>

wrote:



On 01/10/2018 12:01 PM, Daan Hoogland wrote:

I'd say remove as much functionality as we can from 'our' StringUtils and

phase them out asap.


Yes, but such a PR would be invasive and would be difficult to merge and

also break a lot of other code.

It's not easy since it will touch a lot, but I mean, a lot of files.

Our StringUtils was a very good solution, but the Apache one is better I
think.

Wido


On Wed, Jan 10, 2018 at 11:59 AM, Wido den Hollander <w...@widodh.nl>


wrote:

Hi,


We have com.cloud.utils.StringUtils which has a few nice functions, but
throughout the code I also see org.apache.commons.lang.StringUtils

They both provide about the same functionality, but which one do we
prefer?

I'd say org.apache.commons.lang.StringUtils as that allows us to
remove
our own StringUtils, but we could also have 'our' StringUtils simply
be a
wrapper around org.apache.commons.lang.StringUtils

Opinions?

Wido












--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

DZone article on software management

[Ron Wheeler]

For those who are interested in process.

This is an interesting summary of "Best Practices" for teamwork on 
software projects.


https://dzone.com/storage/assets/7529578-rc-167-softwareconfigurationmanagementpatterns.pdf

It describes practices that I believe are currently followed in the 
Cloudstack team.


There is an good discussion about SCM and how to manage a stable 
development line with simple rules for managing private development 
branches.


You may have to sign up for DZone to get this. It is free and I guess 
that you can drop out at any time.
I understand that some will not want to bother but it is interesting 
reading and may have some sections that explicitly state policies that 
Cloudstack developers are following (or not).


http://www.berczuk.com/ is the author's home page

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Known trillian test failures

[Ron Wheeler]

While cleaning up the tests is there any value in splitting out tests 
that are redundant
- test that test low level functions whose failures will be picked up in 
other tests of higher level functions

- tests that are run on modules that "never" change.

The lower level test may still be useful for testing a change to a low 
level function or for tracking down a failure in a higher level function 
that uses a low level routine but may not add much value to a test suite 
that is run frequently.


Would this reduce the amount of time taken to do a full test at the 
expense of some increased risk that an edge case might be missed?
Would setting aside the clutter allow the team to focus on the tests 
that really matter?


Ron

On 20/12/2017 1:21 PM, Paul Angus wrote:

Hi Marc-Aurèle, (and everyone else)

The title probably is slightly incorrect.  It should really say known Marvin 
test failures.  Trillian is the automation that creates the environments to run 
the tests in, the tests are purely those that are in Marvin codebase so anyone 
can repeat them.  In fact we would like to see other people running the tests 
in their environments and comparing the results.

With regard to the failing tests, I agree, that it would be dangerous to hide 
failures.
I would like to see however, a matrix of known good and known bad tests, and 
any PR that then fails known good tests has a problem.
With a visible list of known bad tests we can 'not fail' a PR due to failing a 
bad test, and also there would be a list of bad tests which the community can 
attack and whittle down the list until all tests *should* pass.

That way we can make clear (automated) decisions on pass/fail.  Rather than get 
a list of pass/fails that we then have to interpret.



Kind regards,

Paul Angus

paul.an...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
   
  



-Original Message-
From: Marc-Aurèle Brothier [mailto:ma...@exoscale.ch]
Sent: 20 December 2017 12:56
To: dev@cloudstack.apache.org
Subject: Known trillian test failures

@rhtyd

Could something be done to avoid confusing people pushing PR to have trillian 
test failures, which apparently are know to fail all the time or often? I know 
it's hard to keep the tests in good shape and make them run smoothly but I find 
it very disturbing and therefore I have to admit I'm not paying attention to 
those outputs, sadly.

Skipping them adds the high risk of never getting fixed... I would hope that 
someone having full access the the management & agent's logs could fix them, 
since AFAIK they aren't available.

Cheers



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Call for participation: Issue triaging and PR review/testing

[Ron Wheeler]

ee things slow down a bit. But
I think we already have enough PRs open for 4.11

We should be able to get out a proper release again.

Wido


[1] http://markmail.org/message/mszlluye35acvn2j

Regards,
Rohit Yadav
http://rohityadav.cloud | @rhtyd

__?.o/   Apache CloudStack
   ()# The best of CloudStack is yet to come!
(___(_)   https://cloudstack.apache.org




--
With best regards, Ivan Kudryavtsev
Bitworks Software, Ltd.
Cell: +7-923-414-1515
WWW: http://bitworks.software/ <http://bw-sw.com/>

rohit.ya...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
   
  



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Call for participation: Issue triaging and PR review/testing

[Ron Wheeler]

Is there a document (wiki page?) that captures the discussion about what 
was missed in the release of 4.10?


Ron

On 13/12/2017 9:53 AM, Ivan Kudryavtsev wrote:

Hi, Rene.

That sounds great, chaos engineering and controlled experiments are great
tools, smoke tests improvements are also subject of discussion and I think
that UAT (user acceptance tests) suite should be designed finally. It's
important to a business to have one. It's important to the community to
have one, otherwise quality can not be expected. I think the policy should
be developed which forces and motivates movement toward the direction
observed.

13 дек. 2017 г. 19:59 пользователь "Rene Moser" <m...@renemoser.net>
написал:


Hi all

On 12/13/2017 05:04 AM, Ivan Kudryavtsev wrote:

Hello, devs, users, Rohit. Have a good day.

Rohit, you intend to freeze 4.11 on 8 january and, frankly speaking, I

see

risks here. A major risk is that 4.10 is too buggy and it seems nobody

uses

it actually right now in production because it's unusable, unfortunately,
so we are planning to freeze 4.11 which stands on untested 4.10 with a

lot

of lacks still undiscovered and not reported. I believe it's a very
dangerous way to release one more release with bad quality. Actually,
marvin and units don't cover regressions I meet in 4.10. Ok, let's take a
look at new one our engineers found today in 4.10:

So, the point is, how do we (users, devs, all) improve quality?

Marvin is great for smoke testing but CloudStack is dealing with many
infra vendor components, which are not covered by the tests. How can we
detect flows not covered by marvin?

For me, I decided (independent of this discussion) to write integration
tests in a way one would not expect, not following the "happy path":

Try to break CloudStack, to make a better CloudStack.

Put a chaos monkey in your test infra: Shut down storage, kill a host,
put latency on storage, disable network on hosts, make load on a host.
read only fs on a cluster wide primary fs. shut down a VR, remove a VR.

Things that can happen!

Not surprisingly I use Ansible. It has an extensive amount of modules
which can be used to battle prove anything of your infra. Ansible
playbooks are fairly easy to write, even when you are not used to write
code.

I will share my works when ready.

René








--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [DISCUSS] Replace the default built-in centos template

[Ron Wheeler]

Sounds good.

Minimal CentOS 7 with Docker and Kubernetes ready to go?



On 10/12/2017 6:13 PM, Nux! wrote:

Good initiative, EL5 is long dead though it's still useful for initial tests 
and so on.
As long as people can still login with "password" at the console, I am fine with 
cloud-init & co in a CentOS 7 VM.

How about we go the extra mile and set up a "market place" for the main OS 
templates, like I do at openvm.eu, but under Apache Cloudstack(tm) auspice?

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -

From: "Rohit Yadav" <rohit.ya...@shapeblue.com>
To: "dev" <dev@cloudstack.apache.org>
Sent: Saturday, 9 December, 2017 14:36:48
Subject: [DISCUSS] Replace the default built-in centos template
All,

I would like to kick a discussion thread on replacing the current centos5 based
built-in guest vm template with a systemd and cloud-init enabled centos7 one?

Thoughts, comments?

Regards.

Get Outlook for Android<https://aka.ms/ghei36>


rohit.ya...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [DISCUSS] Replace the default built-in centos template

[Ron Wheeler]

+1
On 09/12/2017 1:18 PM, Milamber wrote:


Great idea. Perhaps using the official CentOS 7 generic image

https://wiki.centos.org/Download
http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2 


or
http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2.xz 
(need to update the download method to add the support of XZ format)




On 09/12/2017 14:36, Rohit Yadav wrote:

All,

I would like to kick a discussion thread on replacing the current 
centos5 based built-in guest vm template with a systemd and 
cloud-init enabled centos7 one?


Thoughts, comments?

Regards.

Get Outlook for Android<https://aka.ms/ghei36>


rohit.ya...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue






--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: CloudStack LTS EOL date?

[Ron Wheeler]

"supported for a minimum of 6 months after next LTS release or a total period of 24 
months, whichever is greater"

Do you mean:

"supported for a minimum of 6 months after next LTS release or minimum of 24 months 
after initial release, whichever is greater"

The web site should be updated to reflect the current policy and kept up 
to date as the policy changes.
New users do not have the benefit of all of this discussion so they go 
by what the web site says and make their judgments about stability and 
support based on what it says.


It will be unusual for users to object to an extension of LTS if the 
initial commitment needs altering.



Ron

On 27/11/2017 12:27 PM, Paul Angus wrote:

Hi Rene,

note: I'm only stating what the original intent was when LTS was originally 
proposed.  I'm not trying to dictate what we must do now or in the future.

... The LTS scheme was designed when there was a release coming out every one 
or two months, and these releases were effectively only receiving fixes for a 
month or two.

To answer your questions (taking into account the note above)- 4.9 was an LTS 
version, which meant that there would be a 4.9.1, 4.9.2..4.9.6... for a 
period of 2 years.
4.9.x was the latest 'version' at the beginning of 2017.
Unfortunately, it was also the latest version in the middle of 2017. So in 
mid-2017 we took the latest version (4.9 again) and said that we would continue 
backporting fix for that version for 2 years from mid 2017.

Some variant of your proposal "6 months after next LTS release (minimum 18 
months)." would also work.
I think something like "supported for a minimum of 6 months after next LTS release 
or a total period of 24 months, whichever is greater" suits what you are saying?


Kind regards,

Paul Angus

paul.an...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
   
  



-Original Message-
From: Rene Moser [mailto:m...@renemoser.net]
Sent: 27 November 2017 09:52
To: dev@cloudstack.apache.org
Subject: Re: CloudStack LTS EOL date?

Hi Paul

On 11/22/2017 05:39 PM, Paul Angus wrote:

HI All,

The current LTS cycle is based on having an LTS release twice a year (at the 
time of design, ACS releases were coming out monthly).

So, twice a year (nominally, January and July) we take the then current version 
of CloudStack, and declare that an LTS version, for which would we would then 
backport fixes for a period of up to 2 years.  Thereby giving end users a 
version of CloudStack which would receive bug fixes for an extended period.

This year however, the current version in January was the same as the
current version in July, therefore 4.9 became the 'July' LTS as well
as January LTS and therefore 4.9 will be supported until summer 2019
(hence the 4.9.3 release)

I and a number of my colleagues remain committed to continue to support 'LTS' 
releases in this fashion (there just wasn't anything really to 'announce' in 
July), which may be why people think that nothing is happening.

With 2 LTS releases a year (6 months apart), 'next LTS +6 months' would only be 
12 months from release.  Which I think is really too short a period for the 
majority of enterprises.  Although we haven't written it this way, the current 
scheme gives a EOL of 'next LTS + 18 months'.

So, I'm in favour of leaving things as they are.   The wiki page looks like it 
needs updating to be clearer (I'm happy to do that)

Does the release of an LTS include minor releases, is a release of 4.9.x an "LTS" 
release? Or is a 4.x an LTS release. My understanding was, that 4.x are new "releases".

My concerns are, we can not guarantee 2 LTS releases per year, can we?

Predicting the future is hard and we should have a more "relative"
sentence how long we support it.

In my opition, there should be an overlapping of support time for at east 6 
monnths (that is why I added +6 months).

What would it cost to change the support time of an LTS like:

"6 months after next LTS release (minimum 18 months)."

Regards
René



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: CloudStack LTS EOL date?

[Ron Wheeler]

gt; написал:


It makes more sense to me too.


On Tue, 2017-11-21 at 12:04 +0100, Rene Moser wrote:

Hi all

The current LTS release is 4.9 which is EOL in June 2018 according
to https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS

AFAIK there are no works planed for a new LTS. The release pace has
slown down (the high pace and leaving users behind fixes was the
reason for the LTS).

I am still pro LTS but in my opinion we should have defined the EOL
in relation of the successor LTS release date: "The EOL of the
current LTS is +6 months after the next LTS release."

Small example:

Current LTS 4.9
Next LTS 4.1x release on 01.04. --> LTS 4.9 is 01.10.

Does this make sense? Other suggestions?

Regards
René



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

A good article on developing large systems

[Ron Wheeler]

https://dzone.com/storage/assets/6002108-dzone-guidetointegration-volumeiv.pdf 
has on page 7:


"The philosophy behind DocumentationDriven API Design or Development is 
simple: from the perspective of a user, if a feature is not documented, 
then it does not exist, and if a feature is documented incorrectly, then 
it is broken."


also

DOCUMENT YOUR API OR FEATURE FIRST
You can do this as you design an API, or later if you’d like to rework 
an existing API. Wherever the documentation becomes complicated or 
difficult to write, revisit the design. This process works because it is 
easier to spot complexity in the documentation than in the code.
Figure out how you are going to describe the feature to users; if it is 
not documented, it does not exist.


DO DOCUMENTATION REVIEWS
Whenever possible, documentation should be reviewed by users before any 
development begins. This also gives you the chance to get your ideas 
peer-reviewed, since it helps users to understand what you are trying to do.


WORK IN PARALLEL
Once documentation has been written, development should commence, 
preferably test-driven development. Both developers and testers can 
start working on the implementation, one focusing on writing code and 
the other on writing automatic tests.


 TESTING
Unit tests should be written to test the features as described in the 
documentation. If the functionality is ever out of alignment with the 
documentation, tests should fail.


 CHANGES
When a feature is being modified, it should be modified 
documentation-first; when documentation is modified, so should the tests 
change. Along with the tests being changed, the coding will also have to 
be modified accordingly.


VERSIONING
Documentation and software should both be versioned, and the versions 
should match so someone working with old versions of software will be 
able to find the proper documentation."



This would seem to make evaluating PRs a lot easier. 3 sets of PRs would 
be have to approved but the approval of each one would be much easier 
and involve a lot less risk.
We would also have much better documentation, much clearer Release Notes 
and full coverage of the test suite.


It would also expand the community by increasing the visibility of 
enhancement project and giving more opportunities for people to get 
involved in testing and coding of enhancements. People who might not 
feel comfortable developing the code might be quite willing to take on 
testing if they wanted to help gt a new feature implemented.



Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Developer Guide - Current Setup Guide?

[Ron Wheeler]

Some employment agreements give ALL work done while employed to the 
employer which makes the CCLA required in some cases even if the work is 
being done on your own time..


Not everyone needs to have a CCLA for their company but people working 
for CloudOps, Shapeblue and other which are allowing their staff to work 
on Apache as part of their jobs must have one on file.


Ron

On 10/07/2017 4:27 PM, Alex Hitchins wrote:

That was my understanding. I'm working on this on my own time, so I have no 
legal concerns over the ownership of work.

I understand it's probably worthwhile in the long run but adds another step 
people may consider too much bother to make a one line change to a URL.


Alexander Hitchins

E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587

-Original Message-
From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
Sent: 10 July 2017 19:21
To: Will Stevens <wstev...@cloudops.com>; dev@cloudstack.apache.org
Subject: Re: Developer Guide - Current Setup Guide?

They do not need to be a committer of software.
I support the documentation in a number of projects where I am not a committer.

The ACL does give you any rights.
It only says that you agree that the rights to ANYTHING that you contribute to 
a project belong to Apache.


Ron


On 10/07/2017 1:50 PM, Will Stevens wrote:

While I agree with some of your points Ron, we also need to make sure
that we are setup to be able to take advantage of motivated people
contributing (especially around documentation) without first requiring
that they become a committer.  That is a bit of a chicken and egg
problem because no one will accept a new committer with zero activity,
so if we didn't give this type of access, then an interested
contributor would never be able to support the project in the ways
know how.

We need as much support on the supporting documentation as we can get,
and we don't have the convenience of mechanisms like 'pull requests'
on wiki content.

My 0.02$ anyway...

*Will Stevens*
CTO

<https://goo.gl/NYZ8KK>

On Mon, Jul 10, 2017 at 1:29 PM, Ron Wheeler
<rwhee...@artifact-software.com
<mailto:rwhee...@artifact-software.com>> wrote:

 You may want to own the wiki content as well as the software.

 A company may want to quote the wiki or incorporate some of it
 into their documentation without having to get the rights from
 each person who contributed to the page.


 Even more complicated if someone posts a design or an enhancement
 and then claims to own it and patent it.

 It is good practice to make sure that Apache owns it all (code,
 docs, test cases, enhancements, patches)  and that you can use it
 all without legal problems under the Apache license.


 Ron


 On 10/07/2017 12:23 PM, Daan Hoogland wrote:

 Why do you say that Ron? You need one to become a committer.
 for the
 wiki we need to recognise you as a contributor. I think you
 need no
 more.

 On Mon, Jul 10, 2017 at 5:10 PM, Ron Wheeler
 <rwhee...@artifact-software.com
 <mailto:rwhee...@artifact-software.com>> wrote:

 Alex,
 Do you have a CLA on file with Apache.
 You should have one to contribute to the wiki.

 Ron

 On 10/07/2017 10:42 AM, Daan Hoogland wrote:

 create your account on cwiki and we can give you access

 On Sun, Jul 9, 2017 at 12:10 AM, Alex Hitchins
 <a...@alexhitchins.com <mailto:a...@alexhitchins.com>>
 wrote:

 Please let me know if there is anything I can do
 to help with this.

 I have an open PR on the repo readme.md
 <http://readme.md>, minor documentation change but
 somehow is breaking the build. My guess is it's
 something unrelated on
 master.

 On 8 Jul 2017, at 22:37, Will Stevens
 <williamstev...@gmail.com
 <mailto:williamstev...@gmail.com>> wrote:

 We need to amend. As of 4.10 we are on jdk 8.

 I will have to review it and see what needs to
 be done to bring it up to
 date.

 On Jul 8, 2017 4:46 PM, "Alex Hitchins"
 <a...@alexhitchins.com
 <mailto:a...@alexhitchins.com>> wrote:

 Asking as I want to be sure I'm getting myself
 setup correctly.

 I appreciate setup guides may not necessitate
 lots of amendments however
 4
 yea

Re: Developer Guide - Current Setup Guide?

[Ron Wheeler]

It is easy to fill out the form and it lets you work on any project.

If you are only going to change a URL, you can just make a request in 
the dev list and someone with an ICLA on file will do it.

It sounds like you are going to do a lot more.

It is just a good habit for the PMC and contributors to get into.
Getting the paperwork done avoids any questions in the future.

If you ever get active on the code side  (testing, code cleanup, etc) 
you already have the ICLA in place.


Ron

On 10/07/2017 4:27 PM, Alex Hitchins wrote:

That was my understanding. I'm working on this on my own time, so I have no 
legal concerns over the ownership of work.

I understand it's probably worthwhile in the long run but adds another step 
people may consider too much bother to make a one line change to a URL.


Alexander Hitchins

E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587

-Original Message-
From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
Sent: 10 July 2017 19:21
To: Will Stevens <wstev...@cloudops.com>; dev@cloudstack.apache.org
Subject: Re: Developer Guide - Current Setup Guide?

They do not need to be a committer of software.
I support the documentation in a number of projects where I am not a committer.

The ACL does give you any rights.
It only says that you agree that the rights to ANYTHING that you contribute to 
a project belong to Apache.


Ron


On 10/07/2017 1:50 PM, Will Stevens wrote:

While I agree with some of your points Ron, we also need to make sure
that we are setup to be able to take advantage of motivated people
contributing (especially around documentation) without first requiring
that they become a committer.  That is a bit of a chicken and egg
problem because no one will accept a new committer with zero activity,
so if we didn't give this type of access, then an interested
contributor would never be able to support the project in the ways
know how.

We need as much support on the supporting documentation as we can get,
and we don't have the convenience of mechanisms like 'pull requests'
on wiki content.

My 0.02$ anyway...

*Will Stevens*
CTO

<https://goo.gl/NYZ8KK>

On Mon, Jul 10, 2017 at 1:29 PM, Ron Wheeler
<rwhee...@artifact-software.com
<mailto:rwhee...@artifact-software.com>> wrote:

 You may want to own the wiki content as well as the software.

 A company may want to quote the wiki or incorporate some of it
 into their documentation without having to get the rights from
 each person who contributed to the page.


 Even more complicated if someone posts a design or an enhancement
 and then claims to own it and patent it.

 It is good practice to make sure that Apache owns it all (code,
 docs, test cases, enhancements, patches)  and that you can use it
 all without legal problems under the Apache license.


 Ron


 On 10/07/2017 12:23 PM, Daan Hoogland wrote:

 Why do you say that Ron? You need one to become a committer.
 for the
 wiki we need to recognise you as a contributor. I think you
 need no
 more.

 On Mon, Jul 10, 2017 at 5:10 PM, Ron Wheeler
 <rwhee...@artifact-software.com
 <mailto:rwhee...@artifact-software.com>> wrote:

 Alex,
 Do you have a CLA on file with Apache.
 You should have one to contribute to the wiki.

 Ron

 On 10/07/2017 10:42 AM, Daan Hoogland wrote:

 create your account on cwiki and we can give you access

 On Sun, Jul 9, 2017 at 12:10 AM, Alex Hitchins
 <a...@alexhitchins.com <mailto:a...@alexhitchins.com>>
 wrote:

 Please let me know if there is anything I can do
 to help with this.

 I have an open PR on the repo readme.md
 <http://readme.md>, minor documentation change but
 somehow is breaking the build. My guess is it's
 something unrelated on
 master.

 On 8 Jul 2017, at 22:37, Will Stevens
 <williamstev...@gmail.com
 <mailto:williamstev...@gmail.com>> wrote:

 We need to amend. As of 4.10 we are on jdk 8.

 I will have to review it and see what needs to
 be done to bring it up to
 date.

 On Jul 8, 2017 4:46 PM, "Alex Hitchins"
 <a...@alexhitchins.com
 <mailto:a...@alexhitchins.com>> wrote:

 Asking as I want to be sure I'm getting myself
 setup correctly.

 I appreciate setup guides may not ne

Re: Developer Guide - Current Setup Guide?

[Ron Wheeler]

https://www.apache.org/licenses/icla.pdf should be filled in and submitted.
It covers all Apache projects so you only do it once. It specifically 
mentions documentation.


It is also important to note that if a contributor works for a company 
and works on Apache projects on company time or has signed an employment 
agreement that gives the employer rights to all work that they do while 
they are employed, Apache needs a corporate CLA  
https://www.apache.org/licenses/cla-corporate.txt wherein the 
corporation cedes the rights to Apache.
Unfortunately the PMC needs to trust the individual contributors to be 
aware of the status of the rights to their work and do the right thing.
If you suspect that a contributor is in this situation, it is worth 
asking the questions about their employment and getting a CCLA signed.


These are not onerous but are a sign that a project takes its work 
seriously and intends to have people integrate their products into 
production environments without having to worry about legal entanglements.


Ron

On 10/07/2017 1:58 PM, Alex Hitchins wrote:

This sounds like it isn't needed currently, correct?

I will see if I can locate my confluence credentials, sure I had these circa 
2013!

Do I assume the broader answer to my question is that this is the most up to 
date resource? I see another person ask noob question so wondered if I had 
missed something.

If anyone with cloudstack chops has a spare 10 minutes to look over the current 
guide with me I'd be more than happy to work the changes back in to the wiki. 
I'll even hand over all rights to Apache.


On 10 Jul 2017, at 18:29, Ron Wheeler <rwhee...@artifact-software.com> wrote:

You may want to own the wiki content as well as the software.

A company may want to quote the wiki or incorporate some of it into their 
documentation without having to get the rights from each person who contributed 
to the page.


Even more complicated if someone posts a design or an enhancement and then 
claims to own it and patent it.

It is good practice to make sure that Apache owns it all (code, docs, test 
cases, enhancements, patches)  and that you can use it all without legal 
problems under the Apache license.


Ron


On 10/07/2017 12:23 PM, Daan Hoogland wrote:
Why do you say that Ron? You need one to become a committer. for the
wiki we need to recognise you as a contributor. I think you need no
more.

On Mon, Jul 10, 2017 at 5:10 PM, Ron Wheeler
<rwhee...@artifact-software.com> wrote:

Alex,
Do you have a CLA on file with Apache.
You should have one to contribute to the wiki.

Ron


On 10/07/2017 10:42 AM, Daan Hoogland wrote:
create your account on cwiki and we can give you access

On Sun, Jul 9, 2017 at 12:10 AM, Alex Hitchins <a...@alexhitchins.com>
wrote:

Please let me know if there is anything I can do to help with this.

I have an open PR on the repo readme.md, minor documentation change but
somehow is breaking the build. My guess is it's something unrelated on
master.


On 8 Jul 2017, at 22:37, Will Stevens <williamstev...@gmail.com> wrote:

We need to amend. As of 4.10 we are on jdk 8.

I will have to review it and see what needs to be done to bring it up to
date.

On Jul 8, 2017 4:46 PM, "Alex Hitchins" <a...@alexhitchins.com> wrote:

Asking as I want to be sure I'm getting myself setup correctly.

I appreciate setup guides may not necessitate lots of amendments however
4
years seemed a long time to go with nothing. Are we still on JDK 6 for
example?

More than happy to amend Confluence with updates as I come across them.


Alexander Hitchins

E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587

-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
Sent: 07 July 2017 21:08
To: dev <dev@cloudstack.apache.org>
Subject: Re: Developer Guide - Current Setup Guide?

Why do you ask, Alex? Is something not working?

Biligual auto correct use.  Read at your own risico


On 7 Jul 2017 9:54 pm, "Alex Hitchins" <a...@alexhitchins.com> wrote:

Hello all,



I note this was last amended 2013, is there a better/more recent
resource for the aspiring CloudStack developer?



https://cwiki.apache.org/confluence/display/CLOUDSTACK/
Setting+up+CloudStack
+Development+Environment+on+Linux









Alexander Hitchins



E: a...@alexhitchins.com

W: alexhitchins.com

M: 07788 423 969

T: 01892 523 587





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Developer Guide - Current Setup Guide?

[Ron Wheeler]

They do not need to be a committer of software.
I support the documentation in a number of projects where I am not a 
committer.


The ACL does give you any rights.
It only says that you agree that the rights to ANYTHING that you 
contribute to a project belong to Apache.



Ron


On 10/07/2017 1:50 PM, Will Stevens wrote:
While I agree with some of your points Ron, we also need to make sure 
that we are setup to be able to take advantage of motivated people 
contributing (especially around documentation) without first requiring 
that they become a committer.  That is a bit of a chicken and egg 
problem because no one will accept a new committer with zero activity, 
so if we didn't give this type of access, then an interested 
contributor would never be able to support the project in the ways 
know how.


We need as much support on the supporting documentation as we can get, 
and we don't have the convenience of mechanisms like 'pull requests' 
on wiki content.


My 0.02$ anyway...

*Will Stevens*
CTO

<https://goo.gl/NYZ8KK>

On Mon, Jul 10, 2017 at 1:29 PM, Ron Wheeler 
<rwhee...@artifact-software.com 
<mailto:rwhee...@artifact-software.com>> wrote:


You may want to own the wiki content as well as the software.

A company may want to quote the wiki or incorporate some of it
into their documentation without having to get the rights from
each person who contributed to the page.


Even more complicated if someone posts a design or an enhancement
and then claims to own it and patent it.

It is good practice to make sure that Apache owns it all (code,
docs, test cases, enhancements, patches)  and that you can use it
all without legal problems under the Apache license.


Ron


On 10/07/2017 12:23 PM, Daan Hoogland wrote:

Why do you say that Ron? You need one to become a committer.
for the
wiki we need to recognise you as a contributor. I think you
need no
more.

On Mon, Jul 10, 2017 at 5:10 PM, Ron Wheeler
<rwhee...@artifact-software.com
<mailto:rwhee...@artifact-software.com>> wrote:

Alex,
Do you have a CLA on file with Apache.
You should have one to contribute to the wiki.

Ron

On 10/07/2017 10:42 AM, Daan Hoogland wrote:

create your account on cwiki and we can give you access

On Sun, Jul 9, 2017 at 12:10 AM, Alex Hitchins
<a...@alexhitchins.com <mailto:a...@alexhitchins.com>>
wrote:

Please let me know if there is anything I can do
to help with this.

I have an open PR on the repo readme.md
<http://readme.md>, minor documentation change but
somehow is breaking the build. My guess is it's
something unrelated on
master.

On 8 Jul 2017, at 22:37, Will Stevens
<williamstev...@gmail.com
<mailto:williamstev...@gmail.com>> wrote:

We need to amend. As of 4.10 we are on jdk 8.

I will have to review it and see what needs to
be done to bring it up to
date.

On Jul 8, 2017 4:46 PM, "Alex Hitchins"
<a...@alexhitchins.com
<mailto:a...@alexhitchins.com>> wrote:

Asking as I want to be sure I'm getting myself
setup correctly.

I appreciate setup guides may not necessitate
lots of amendments however
4
years seemed a long time to go with nothing.
Are we still on JDK 6 for
example?

More than happy to amend Confluence with
updates as I come across them.


Alexander Hitchins

E: a...@alexhitchins.com
<mailto:a...@alexhitchins.com>
W: alexhitchins.com <http://alexhitchins.com>
M: 07788 423 969
T: 01892 523 587

-Original Message-
From: Daan Hoogland
[mailto:daan.hoogl...@gmail.com
<mailto:daan.hoogl...@gmail.com>]
Sent: 07 July 2017 21:08
To: dev <dev@cloudstack.apache.org
<mailto:dev@cloudstack.apache.org>>
Subject: Re: Developer Guide - Current Setup
Guide?

Re: Developer Guide - Current Setup Guide?

[Ron Wheeler]

You may want to own the wiki content as well as the software.

A company may want to quote the wiki or incorporate some of it into 
their documentation without having to get the rights from each person 
who contributed to the page.



Even more complicated if someone posts a design or an enhancement and 
then claims to own it and patent it.


It is good practice to make sure that Apache owns it all (code, docs, 
test cases, enhancements, patches)  and that you can use it all without 
legal problems under the Apache license.



Ron

On 10/07/2017 12:23 PM, Daan Hoogland wrote:

Why do you say that Ron? You need one to become a committer. for the
wiki we need to recognise you as a contributor. I think you need no
more.

On Mon, Jul 10, 2017 at 5:10 PM, Ron Wheeler
<rwhee...@artifact-software.com> wrote:

Alex,
Do you have a CLA on file with Apache.
You should have one to contribute to the wiki.

Ron

On 10/07/2017 10:42 AM, Daan Hoogland wrote:

create your account on cwiki and we can give you access

On Sun, Jul 9, 2017 at 12:10 AM, Alex Hitchins <a...@alexhitchins.com>
wrote:

Please let me know if there is anything I can do to help with this.

I have an open PR on the repo readme.md, minor documentation change but
somehow is breaking the build. My guess is it's something unrelated on
master.


On 8 Jul 2017, at 22:37, Will Stevens <williamstev...@gmail.com> wrote:

We need to amend. As of 4.10 we are on jdk 8.

I will have to review it and see what needs to be done to bring it up to
date.

On Jul 8, 2017 4:46 PM, "Alex Hitchins" <a...@alexhitchins.com> wrote:

Asking as I want to be sure I'm getting myself setup correctly.

I appreciate setup guides may not necessitate lots of amendments however
4
years seemed a long time to go with nothing. Are we still on JDK 6 for
example?

More than happy to amend Confluence with updates as I come across them.


Alexander Hitchins

E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587

-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
Sent: 07 July 2017 21:08
To: dev <dev@cloudstack.apache.org>
Subject: Re: Developer Guide - Current Setup Guide?

Why do you ask, Alex? Is something not working?

Biligual auto correct use.  Read at your own risico


On 7 Jul 2017 9:54 pm, "Alex Hitchins" <a...@alexhitchins.com> wrote:

Hello all,



I note this was last amended 2013, is there a better/more recent
resource for the aspiring CloudStack developer?



https://cwiki.apache.org/confluence/display/CLOUDSTACK/
Setting+up+CloudStack
+Development+Environment+on+Linux









Alexander Hitchins



E: a...@alexhitchins.com

W: alexhitchins.com

M: 07788 423 969

T: 01892 523 587







--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102






--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Developer Guide - Current Setup Guide?

[Ron Wheeler]

Alex,
Do you have a CLA on file with Apache.
You should have one to contribute to the wiki.

Ron

On 10/07/2017 10:42 AM, Daan Hoogland wrote:

create your account on cwiki and we can give you access

On Sun, Jul 9, 2017 at 12:10 AM, Alex Hitchins <a...@alexhitchins.com> wrote:

Please let me know if there is anything I can do to help with this.

I have an open PR on the repo readme.md, minor documentation change but somehow 
is breaking the build. My guess is it's something unrelated on master.


On 8 Jul 2017, at 22:37, Will Stevens <williamstev...@gmail.com> wrote:

We need to amend. As of 4.10 we are on jdk 8.

I will have to review it and see what needs to be done to bring it up to
date.

On Jul 8, 2017 4:46 PM, "Alex Hitchins" <a...@alexhitchins.com> wrote:

Asking as I want to be sure I'm getting myself setup correctly.

I appreciate setup guides may not necessitate lots of amendments however 4
years seemed a long time to go with nothing. Are we still on JDK 6 for
example?

More than happy to amend Confluence with updates as I come across them.


Alexander Hitchins

E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587

-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
Sent: 07 July 2017 21:08
To: dev <dev@cloudstack.apache.org>
Subject: Re: Developer Guide - Current Setup Guide?

Why do you ask, Alex? Is something not working?

Biligual auto correct use.  Read at your own risico


On 7 Jul 2017 9:54 pm, "Alex Hitchins" <a...@alexhitchins.com> wrote:

Hello all,



I note this was last amended 2013, is there a better/more recent
resource for the aspiring CloudStack developer?



https://cwiki.apache.org/confluence/display/CLOUDSTACK/
Setting+up+CloudStack
+Development+Environment+on+Linux









Alexander Hitchins



E: a...@alexhitchins.com

W: alexhitchins.com

M: 07788 423 969

T: 01892 523 587









--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [DISCUSS] drop support for CentOS6 with 4.10

[Ron Wheeler]

CentOS 6 <http://wiki.centos.org/FAQ/CentOS6>



CentOS-6 updates until November 30, 2020

CentOS 7 <http://wiki.centos.org/FAQ/CentOS7>



CentOS-7 updates until June 30, 2024

End of support dates from 
https://wiki.centos.org/FAQ/General#head-fe8a0be91ee3e7dea812e8694491e1dde5b75e6d


Is there any reason why anyone would still be installing CentoOS6 on a 
new installation?
I have not had any trouble running anything on CentoOS 7  that ran on 
CentOS 6.


Is there any reason why someone would want to upgrade Cloudstack on a 
Centos6 installation where upgrading to Centos 7 would be a problem.


It would certainly simplify documentation/instructions if one does not 
have to sort through /etc/init.d... and systemctl ... at every step that 
involves system functions.


Ron


On 09/07/2017 8:46 AM, Pierre-Luc Dion wrote:

Since 4.10 require JDK8, should we drop support for CentOS 6 as OS for
management-server and usage ?

all the Upgrade path tests I've made was by creating new management server
on CentOS 7 that have updated tomcat and openJDK 8.  our packages (RPMs)
install well on centos7 and I'm not away somebody test them on centos6.

Should we call a vote on this?  I'm writing the upgrade part of the release
notes and I would focus on centos7 only. we should also update our Quick
Install Guide...


Thanks,

PL



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Ron Wheeler]

I think you are describing the roles of all of the committers

Is it normal at Apache for the RM to be doing all of this stuff?

I would expect that the RM has a QC role in these activities but others 
are doing the work.


Ron

On 01/07/2017 7:18 PM, Will Stevens wrote:

Oh, and if a system VM is touched, then you have to add in a new system VM
build and install into the CI setup prior to testing...

On Jul 1, 2017 6:41 PM, wrote:

Which is part of the reason the RM job is hard and time consuming.
- checking the PRs have the appropriate tests.
- updating the CI to include the new tests.
- run and report CI for the PR (with very limited CI infra community wide).
- chase PR authors to get their PRs to a point where you are happy they are
not breaking master
- rinse repeat for 200+ PRs...

On Jul 1, 2017 6:34 PM, "Will Stevens" <williamstev...@gmail.com> wrote:

Yes, we can totally reject PRs until we are happy with the associated
tests.

On Jul 1, 2017 5:48 PM, "Alex Hitchins" <a...@alexhitchins.com> wrote:


Out of interest, are there any guidelines/rules in place to reject PR's
without unit tests?




Alexander Hitchins

E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587

-Original Message-
From: Paul Angus [mailto:paul.an...@shapeblue.com]
Sent: 30 June 2017 21:58
To: dev@cloudstack.apache.org
Subject: RE: [DISCUSS] - Releases, Project Management & Funding Thereof

Taken from a talk on CloudStack testing [1]...

There are Many, many, MANY permutations of a CloudStack deployment….
• Basic / Advanced
• Local / shared / mixed storage
• More than 8 common hypervisor types/versions • 4 or 5 Management server
OS possibilities • That’s 144 combinations only looking the basics.

[1] https://www.slideshare.net/ShapeBlue/cloudstack-eu-user-grou
p-trillian?qid=74ff2be0-664c-4bca-a3dc-f30d880ca088==_search=1

Trillian [2], can create any of those, and multiple at the same time, but
the amount of hardware required to do that means that we have to pick our
battles. Running the blueorangutan bot command '@blueorangutan matrix' in a
PR will run the smoke test suite against a PR using 3 environments, one
each of KVM, XenServer and vSphere and takes around 8 hours.

But that is only looking for major regressions.  A full component test run
takes around 5 days to run and is riddled with bugs in the tests.

Ultimately these are still of limited scope, few people are as diligent as
say Mike T in creating practical marvin tests for their code / features.

[2] https://github.com/shapeblue/Trillian

Therefore we need hardware to run tests on, but more importantly we need
the tests to exist and work in the first place.  Then we can really do
something.



paul.an...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue




-Original Message-
From: Alex Hitchins [mailto:a...@alexhitchins.com]
Sent: 30 June 2017 21:34
To: dev@cloudstack.apache.org; dev@cloudstack.apache.org
Subject: RE: [DISCUSS] - Releases, Project Management & Funding Thereof

Consultation with users is something that should definite be done. Canvas
as many as possible.

I agree that most people will be running test environments before full
rollout of any technology, I guess see it a little from a CTO eyes - why
shortlist a technology that doesn't even endorse its own releases?

Hopefully we will get some more replies to this thread from other
CloudStack enthusiasts to help shape this conversation.

I'm setting up a new development environment now to get my hands mildly
soiled. Going the Windows route again. Fancy a challenge for the weekend.




Alexander Hitchins

E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587

-Original Message-
From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
Sent: 30 June 2017 21:08
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] - Releases, Project Management & Funding Thereof


On 30/06/2017 3:28 PM, Alex Hitchins wrote:

We can't validate all scenarios no, hence suggesting several common

setups as a reasonable baseline. I like the idea of users posting their
hardware and versions as a community endeavour.

I strongly feel there should be an established, physical setup that the

release team have access to in order to validate a release.

This is perhaps something that should be requested from the user community.
I would expect that anyone running Cloudstack in production on a major
site would have a test setup and might be very happy to have the dev team
test on their setup.
This would save them a lot of resources at the expense of a bit of time on
their test environment.


If this was some random cat meme generator on GitHub, I'd accept the

risk in running an untested version. For something I'd be running my
business on however I'd expect there being some weight behind the release.

Perhaps I have

Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Ron Wheeler]

Do all of these combinations need to be fully tested for each release?

What are the combinations that have been tested for the current release?

How many of these combinations are known to be running in production?

How many of these production organizations have test environments that 
could be used? And operations staff that could run the tests.
They will test anyway so it is mostly a change to timing and the actual 
scripts.
They may be able to augment the existing scripts with the test scripts 
that they are using or work on the completion of the scripts already 
planned.


I am unsure what Paul means by "we need hardware to run tests on".
Clearly hardware is required for testing but it would not seem to matter 
where the hardware exists or who owns it as long as it is available.


Is there a list of tests that are missing?
Is the test suite documented so that end-users can actually use the 
tests on their own test systems?


This is a bit of a switch in thinking about testing and about the role 
of the users in the release management process but it has some benefits.
The testing function of the release team switches to a project 
management role that involves tracking and coaching the testing ecosystem.


Ron




On 30/06/2017 4:57 PM, Paul Angus wrote:

Taken from a talk on CloudStack testing [1]...

There are Many, many, MANY permutations of a CloudStack deployment….
• Basic / Advanced
• Local / shared / mixed storage
• More than 8 common hypervisor types/versions
• 4 or 5 Management server OS possibilities
• That’s 144 combinations only looking the basics.

[1] 
https://www.slideshare.net/ShapeBlue/cloudstack-eu-user-group-trillian?qid=74ff2be0-664c-4bca-a3dc-f30d880ca088==_search=1

Trillian [2], can create any of those, and multiple at the same time, but the 
amount of hardware required to do that means that we have to pick our battles. 
Running the blueorangutan bot command '@blueorangutan matrix' in a PR will run 
the smoke test suite against a PR using 3 environments, one each of KVM, 
XenServer and vSphere and takes around 8 hours.

But that is only looking for major regressions.  A full component test run 
takes around 5 days to run and is riddled with bugs in the tests.

Ultimately these are still of limited scope, few people are as diligent as say 
Mike T in creating practical marvin tests for their code / features.

[2] https://github.com/shapeblue/Trillian

Therefore we need hardware to run tests on, but more importantly we need the 
tests to exist and work in the first place.  Then we can really do something.



paul.an...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
   
  



-Original Message-
From: Alex Hitchins [mailto:a...@alexhitchins.com]
Sent: 30 June 2017 21:34
To: dev@cloudstack.apache.org; dev@cloudstack.apache.org
Subject: RE: [DISCUSS] - Releases, Project Management & Funding Thereof

Consultation with users is something that should definite be done. Canvas as 
many as possible.

I agree that most people will be running test environments before full rollout 
of any technology, I guess see it a little from a CTO eyes - why shortlist a 
technology that doesn't even endorse its own releases?

Hopefully we will get some more replies to this thread from other CloudStack 
enthusiasts to help shape this conversation.

I'm setting up a new development environment now to get my hands mildly soiled. 
Going the Windows route again. Fancy a challenge for the weekend.




Alexander Hitchins

E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587

-Original Message-----
From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
Sent: 30 June 2017 21:08
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] - Releases, Project Management & Funding Thereof


On 30/06/2017 3:28 PM, Alex Hitchins wrote:

We can't validate all scenarios no, hence suggesting several common setups as a 
reasonable baseline. I like the idea of users posting their hardware and 
versions as a community endeavour.

I strongly feel there should be an established, physical setup that the release 
team have access to in order to validate a release.

This is perhaps something that should be requested from the user community.
I would expect that anyone running Cloudstack in production on a major site 
would have a test setup and might be very happy to have the dev team test on 
their setup.
This would save them a lot of resources at the expense of a bit of time on 
their test environment.


If this was some random cat meme generator on GitHub, I'd accept the risk in 
running an untested version. For something I'd be running my business on 
however I'd expect there being some weight behind the release.

Perhaps I have unrealistic expectations!

Not at all.
Your expectations might be the key to making a pitch to the user community for 
some help from people and organizations that are not interest

Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Ron Wheeler]

On 30/06/2017 3:28 PM, Alex Hitchins wrote:

We can't validate all scenarios no, hence suggesting several common setups as a 
reasonable baseline. I like the idea of users posting their hardware and 
versions as a community endeavour.

I strongly feel there should be an established, physical setup that the release 
team have access to in order to validate a release.


This is perhaps something that should be requested from the user community.
I would expect that anyone running Cloudstack in production on a major 
site would have a test setup and might be very happy to have the dev 
team test on their setup.
This would save them a lot of resources at the expense of a bit of time 
on their test environment.



If this was some random cat meme generator on GitHub, I'd accept the risk in 
running an untested version. For something I'd be running my business on 
however I'd expect there being some weight behind the release.

Perhaps I have unrealistic expectations!


Not at all.
Your expectations might be the key to making a pitch to the user 
community for some help from people and organizations that are not 
interested in writing code but have a major interest in testing.
In addition to access to test equipment, this might actually get new 
people on the team with the right skills required to extend the test 
scripts and test procedure documentation.


Does anyone have a list of the configuration specifications that are 
required to test a new release?


Would it help to approach major users of Cloudstack with a direct 
request for use of their test equipment and QA staff in return for early 
access to new releases and testing on their hardware?


Ron



Alexander Hitchins

E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587

-Original Message-
From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
Sent: 30 June 2017 20:13
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] - Releases, Project Management & Funding Thereof

On 30/06/2017 2:19 PM, Alex Hitchins wrote:

Releasing against a defined reference rig would be a very good idea, especially 
if we could replicate several.

It concerns me slightly that we are building a platform we want to promote 
people to deploy in enterprise environments with the caveat 'run at your own 
risk'.

There is no choice as near as I can tell.
It seems that there are too many combinations of hardware, network 
configurations and OSs to guarantee that a release will work on all of them and 
still get a release delivered.
As Will pointed out, the Release Team does not have access to every combination 
where previous releases are in production use, to test the new release 
candidate.

Currently it may be  not very explicit about what are the fully tested 
configurations and from what Will said, I gather that there is no policy saying 
what the minimum test set is to declare a release ready to go.

There is no reason preventing a release being tested after release by an end-user or a 
developer and adding to the release documentation something to the effect that 
"Users have reported that this release has been put into production on XYZ 
configuration with no modifications."
This at least gets the release out the door for the 95% of the users that do 
not have an XYZ rather than waiting for someone with an XYZ to find time to 
test it.

It may also encourage companies using or selling XYZs to put up some resources 
(hardware and people) dedicated to testing so that they get into the initial 
release.

Ron


We need to up our game.

'We' he says, after two years MIA!


On 30 Jun 2017, at 18:41, Ron Wheeler <rwhee...@artifact-software.com> wrote:

How much time is there between a feature freeze and the RC being cut.?
Do people know far enough in advance that their feature is in or out and if in 
must be ready to go to a RC release by such and such a date?

Is the use case testing well defined - hardware, configurations, etc.
Can you put out a release that says: "This release has been tested on these 
configurations (A, B ,C) but the following configurations/use cases are not yet fully 
tested and other configuration may be used at your own risk after your own internal tests 
have been run successfully."
Is there any concept that "Cloudstack is verified to run on the following 
configurations and should also run on these configurations but has not been tested fully. 
It may run on these configurations but is not tested during the release cycle."

Ron


On 30/06/2017 1:14 PM, Will Stevens wrote:
Have not looked at Release Tsar, but worth checking out.

In general, the biggest problem we have with releasing on a schedule
is the lack of a CI setup which covers the entire software. Or at
least a 'supported' set of features. This means that the release is
always bound to a bunch of volunteers getting around to testing
their use case. Solidfire and Nuage are pretty good about getti

Re: ***UNCHECKED*** Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Ron Wheeler]

Rewritten to have sentences that parse into some understandable English.


If the plan is to do several releases each year, something has to change 
in the process.


Any idea about what tasks took up most of the time?

Were there any specific issues that ate up more time than you expected.

Would breaking Cloudstack into separately modules that are separately 
released by different teams make things more manageable?
At some point, one would expect that the APIs would get stabilized so 
that modules could be upgraded without affecting the whole system.


Obviously some changes would require mods to more than one module but 
depending on how one defines the releasable packages, many changes 
should not.


This may get into the case where the current releases only supports part 
of the functionality that the end user needs and they may have to wait a 
week or 2 to find a set of packages that fully supports their particular 
case.
However in the meantime, new functionality can be released to the rest 
of the user community that does not need this case.


This would allow bug fix releases to get out the door quicker if they 
only affected one module.
It would also reduce the testing of each release by a lot and might make 
tests to be more complete on key areas.


It might help users get new functionality into production if they are 
only upgrade part of the system at one time. I would expect a lot less 
testing to be required if only the admin user interface is changing.


It might also expand the dev community as people with interests limited 
to one area (UI, networking hardware) might feel sufficiently 
knowledgeable to contribute.



Ron


On 30/06/2017 1:48 PM, Will Stevens wrote:

I am not doing much right now because our company has many other things on
the go.

For about the first 6 months of 2016 CloudOps donated my time full time to
act as the release manager of 4.9. That is not something we or I can
sustain. Which is part of the problem.

On Jun 30, 2017 1:28 PM, "Ron Wheeler" <rwhee...@artifact-software.com>
wrote:


How many companies are funding staff now to work on Cloudstack? How much
time?
How many FTEs does that come to if one adds it all up?

It is harder to get people who are working on their own time to do
administrative tasks on a tight schedule.

If someone is working for a company that is expecting the person to be
doing "cloudstack stuff", it may be possible to convince the company to
dedicate part of that person's time to release management.

A RM doing it all may be harder to fund/organize than a Release Team. Not
all of the tasks have to be done in sequence or by one person.

Ron

On 30/06/2017 1:13 PM, Wido den Hollander wrote:


Op 30 juni 2017 om 18:09 schreef Paul Angus <paul.an...@shapeblue.com>:


We could probably split this topic down also

I think I may have mentioned previously  my view on how we have
somewhat shot ourselves in the foot with the release process this time
around.  I think that for the most part, people have been well intentioned,
and have been trying to 'make this release as good as possible' which is
counter-productive, as it's been introducing new blockers.

True. But still, somebody who dedicated 5 days a week on releases and

keeping track of the project is still very welcome I think.

I'm not sure we have a problem in our 'loosely-agreed' process, it's just

that repeatedly people have ignored it.

I wouldn't say ignore it, but maybe forgotten about the process with all

the best intentions.

WRT a full-time release manager, I suspect that they would find that "you

can lead a horse to water, but you can't make it drink".  They would not be
able to compel anyone to 'hurry up and fix that bug you created', although
I guess maybe they could pull a feature if the author(s) didn't sort it out.

Because ultimately a release manager, paid or otherwise should only be
doing what the 'community' decides the release manager's role is.  So we
need to be clear about how we want releases to work before worrying about
who manages that.

Somebody who reverts a PR or commit to get to a proper release is

probably a good thing. RM is a busy task and done in spare time. That's not
always easy.

Other projects like Ceph have a dedicated RM who is busy the whole week
with just the new release.

We could use such a person, but we would need the funding.

How much would that cost? Well, you need to keep the overhead down. A few
companies donating 10k per year should probably allow you to hire a person.

Wido

Kind regards,

Paul Angus

paul.an...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue


-Original Message-
From: Alex Hitchins [mailto:a...@alexhitchins.com]
Sent: 30 June 2017 15:05
To: dev@cloudstack.apache.org
Subject: RE: [DISCUSS] - Releases, Project Management & Funding Thereof

I am in complete agreement with you. Also on your other reply regards t

Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Ron Wheeler]

On 30/06/2017 2:19 PM, Alex Hitchins wrote:

Releasing against a defined reference rig would be a very good idea, especially 
if we could replicate several.

It concerns me slightly that we are building a platform we want to promote 
people to deploy in enterprise environments with the caveat 'run at your own 
risk'.

There is no choice as near as I can tell.
It seems that there are too many combinations of hardware, network 
configurations and OSs to guarantee that a release will work on all of 
them and still get a release delivered.
As Will pointed out, the Release Team does not have access to every 
combination where previous releases are in production use, to test the 
new release candidate.


Currently it may be  not very explicit about what are the fully tested 
configurations and from what Will said, I gather that there is no policy 
saying what the minimum test set is to declare a release ready to go.


There is no reason preventing a release being tested after release by an 
end-user or a developer and adding to the release documentation 
something to the effect that "Users have reported that this release has 
been put into production on XYZ configuration with no modifications." 
This at least gets the release out the door for the 95% of the users 
that do not have an XYZ rather than waiting for someone with an XYZ to 
find time to test it.


It may also encourage companies using or selling XYZs to put up some 
resources (hardware and people) dedicated to testing so that they get 
into the initial release.


Ron



We need to up our game.

'We' he says, after two years MIA!


On 30 Jun 2017, at 18:41, Ron Wheeler <rwhee...@artifact-software.com> wrote:

How much time is there between a feature freeze and the RC being cut.?
Do people know far enough in advance that their feature is in or out and if in 
must be ready to go to a RC release by such and such a date?

Is the use case testing well defined - hardware, configurations, etc.
Can you put out a release that says: "This release has been tested on these 
configurations (A, B ,C) but the following configurations/use cases are not yet fully 
tested and other configuration may be used at your own risk after your own internal tests 
have been run successfully."
Is there any concept that "Cloudstack is verified to run on the following 
configurations and should also run on these configurations but has not been tested fully. 
It may run on these configurations but is not tested during the release cycle."

Ron


On 30/06/2017 1:14 PM, Will Stevens wrote:
Have not looked at Release Tsar, but worth checking out.

In general, the biggest problem we have with releasing on a schedule is the
lack of a CI setup which covers the entire software. Or at least a
'supported' set of features. This means that the release is always bound to
a bunch of volunteers getting around to testing their use case. Solidfire
and Nuage are pretty good about getting some CI run on some pieces.
Trillian is great for covering a portion of the tests, but it currently
does not cover the whole software use case. We also need more trillian
deployments in the wild to support the CI initiative.

We do need to be stricter about nothing going in after an RC is cut but
blockers. The limited CI coverage and the dependence on a few people for
testing exasperates this problem.

So there is multiple layers to this. I think someone dedicates to the RM
role would help this a lot because they would have a single community focus
mandate, so it is in their best interest to implement a flow which does not
inhibit their ability to deliver on their mandate.

On Jun 30, 2017 12:53 PM, "Ron Wheeler" <rwhee...@artifact-software.com>
wrote:


Perhaps a Release Tsar would be a better solution.
The RM needs to have absolute control over what is in or out.
Reasonable discussion allowed and then a decision once the RM feels that
the case has been fully explored and that a positive vote is expected.

The importance on meeting deadlines needs to have a higher priority. If a
feature/fix can not meet the quality/testing threshold on time then it gets
dropped from the RC and scheduled for the next release.

A few cycles of a bit of ruthlessness should get everyone`s intention and
shorten the release cycle.

Meeting release schedules would also reduce the pain of a feature being
deferred.
According to the schedule proposed last year,(https://cwiki.apache.org
/confluence/display/CLOUDSTACK/%5BPROPOSAL%5D+2016-2017+
Release+Cycle+and+Calendar)
  Cloudstack 4.9.10 (LTS) , 5.04.0 (LTS) as well as 5.1.3.0 (maintenance)
5.2.1.0 (Maintenance) were released June 2017.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure
seems to be pretty reasonable. The RM probably needs to moderate the vote
and explain what -1 votes mean to product credibility if they delay the
release. Negative votes because someone`s new feature did not make it
should be igno

Re: ***UNCHECKED*** Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Ron Wheeler]

If the plan is to do several releases each year, something has to change 
in the process.


Any idea about what tasks took up most of the time?

Were there any specific issues that ate up more time than you expected.

Would breaking Cloudstack into separately modules that are separately 
released by different teams make things more manageable?
At some point, one would expect that the APIs would get stabilized so 
that modules could be upgraded without affecting the whole system.
Obviously some changes would require mods to more than one module but 
depending on how one defines the releasable packages, many changes 
should not.
This may get into the case where part of the current releases on support 
part of the functionality that the end user needs and they may have to 
wait a week or 2 to find a set of packages that fully supports their 
particular case but in the meantime, new functionality can be released 
to the rest of the user community that does not need this case.
This would allow bug fix releases to get out the door quicker if they 
only affected one module.
It would also reduce the testing of each release by a lot and might 
tests to be more complete on key areas.


Ron


On 30/06/2017 1:48 PM, Will Stevens wrote:

I am not doing much right now because our company has many other things on
the go.

For about the first 6 months of 2016 CloudOps donated my time full time to
act as the release manager of 4.9. That is not something we or I can
sustain. Which is part of the problem.

On Jun 30, 2017 1:28 PM, "Ron Wheeler" <rwhee...@artifact-software.com>
wrote:


How many companies are funding staff now to work on Cloudstack? How much
time?
How many FTEs does that come to if one adds it all up?

It is harder to get people who are working on their own time to do
administrative tasks on a tight schedule.

If someone is working for a company that is expecting the person to be
doing "cloudstack stuff", it may be possible to convince the company to
dedicate part of that person's time to release management.

A RM doing it all may be harder to fund/organize than a Release Team. Not
all of the tasks have to be done in sequence or by one person.

Ron

On 30/06/2017 1:13 PM, Wido den Hollander wrote:


Op 30 juni 2017 om 18:09 schreef Paul Angus <paul.an...@shapeblue.com>:


We could probably split this topic down also

I think I may have mentioned previously  my view on how we have
somewhat shot ourselves in the foot with the release process this time
around.  I think that for the most part, people have been well intentioned,
and have been trying to 'make this release as good as possible' which is
counter-productive, as it's been introducing new blockers.

True. But still, somebody who dedicated 5 days a week on releases and

keeping track of the project is still very welcome I think.

I'm not sure we have a problem in our 'loosely-agreed' process, it's just

that repeatedly people have ignored it.

I wouldn't say ignore it, but maybe forgotten about the process with all

the best intentions.

WRT a full-time release manager, I suspect that they would find that "you

can lead a horse to water, but you can't make it drink".  They would not be
able to compel anyone to 'hurry up and fix that bug you created', although
I guess maybe they could pull a feature if the author(s) didn't sort it out.

Because ultimately a release manager, paid or otherwise should only be
doing what the 'community' decides the release manager's role is.  So we
need to be clear about how we want releases to work before worrying about
who manages that.

Somebody who reverts a PR or commit to get to a proper release is

probably a good thing. RM is a busy task and done in spare time. That's not
always easy.

Other projects like Ceph have a dedicated RM who is busy the whole week
with just the new release.

We could use such a person, but we would need the funding.

How much would that cost? Well, you need to keep the overhead down. A few
companies donating 10k per year should probably allow you to hire a person.

Wido

Kind regards,

Paul Angus

paul.an...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue


-Original Message-
From: Alex Hitchins [mailto:a...@alexhitchins.com]
Sent: 30 June 2017 15:05
To: dev@cloudstack.apache.org
Subject: RE: [DISCUSS] - Releases, Project Management & Funding Thereof

I am in complete agreement with you. Also on your other reply regards to
a FT release manager.

If 'we' don't go down this line, more and more people will follow the
Cosmic/Schuberg Philis path or even use Cosmic instead.

I'm encouraged by your response. Sounds like a few others hold the same
concerns.


Alexander Hitchins

E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587

-Original Message-
From: Will Stevens [mailto:williamstev...@gmail.com]
Sent: 30 June 2017 14:54
To: d

Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Ron Wheeler]

How much time is there between a feature freeze and the RC being cut.?
Do people know far enough in advance that their feature is in or out and 
if in must be ready to go to a RC release by such and such a date?


Is the use case testing well defined - hardware, configurations, etc.
Can you put out a release that says: "This release has been tested on 
these configurations (A, B ,C) but the following configurations/use 
cases are not yet fully tested and other configuration may be used at 
your own risk after your own internal tests have been run successfully."
Is there any concept that "Cloudstack is verified to run on the 
following configurations and should also run on these configurations but 
has not been tested fully. It may run on these configurations but is not 
tested during the release cycle."


Ron

On 30/06/2017 1:14 PM, Will Stevens wrote:

Have not looked at Release Tsar, but worth checking out.

In general, the biggest problem we have with releasing on a schedule is the
lack of a CI setup which covers the entire software. Or at least a
'supported' set of features. This means that the release is always bound to
a bunch of volunteers getting around to testing their use case. Solidfire
and Nuage are pretty good about getting some CI run on some pieces.
Trillian is great for covering a portion of the tests, but it currently
does not cover the whole software use case. We also need more trillian
deployments in the wild to support the CI initiative.

We do need to be stricter about nothing going in after an RC is cut but
blockers. The limited CI coverage and the dependence on a few people for
testing exasperates this problem.

So there is multiple layers to this. I think someone dedicates to the RM
role would help this a lot because they would have a single community focus
mandate, so it is in their best interest to implement a flow which does not
inhibit their ability to deliver on their mandate.

On Jun 30, 2017 12:53 PM, "Ron Wheeler" <rwhee...@artifact-software.com>
wrote:


Perhaps a Release Tsar would be a better solution.
The RM needs to have absolute control over what is in or out.
Reasonable discussion allowed and then a decision once the RM feels that
the case has been fully explored and that a positive vote is expected.

The importance on meeting deadlines needs to have a higher priority. If a
feature/fix can not meet the quality/testing threshold on time then it gets
dropped from the RC and scheduled for the next release.

A few cycles of a bit of ruthlessness should get everyone`s intention and
shorten the release cycle.

Meeting release schedules would also reduce the pain of a feature being
deferred.
According to the schedule proposed last year,(https://cwiki.apache.org
/confluence/display/CLOUDSTACK/%5BPROPOSAL%5D+2016-2017+
Release+Cycle+and+Calendar)
  Cloudstack 4.9.10 (LTS) , 5.04.0 (LTS) as well as 5.1.3.0 (maintenance)
5.2.1.0 (Maintenance) were released June 2017.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure
seems to be pretty reasonable. The RM probably needs to moderate the vote
and explain what -1 votes mean to product credibility if they delay the
release. Negative votes because someone`s new feature did not make it
should be ignored.

Ron

On 30/06/2017 12:09 PM, Paul Angus wrote:


We could probably split this topic down also

I think I may have mentioned previously  my view on how we have
somewhat shot ourselves in the foot with the release process this time
around.  I think that for the most part, people have been well intentioned,
and have been trying to 'make this release as good as possible' which is
counter-productive, as it's been introducing new blockers.

I'm not sure we have a problem in our 'loosely-agreed' process, it's just
that repeatedly people have ignored it.

WRT a full-time release manager, I suspect that they would find that "you
can lead a horse to water, but you can't make it drink".  They would not be
able to compel anyone to 'hurry up and fix that bug you created', although
I guess maybe they could pull a feature if the author(s) didn't sort it out.

Because ultimately a release manager, paid or otherwise should only be
doing what the 'community' decides the release manager's role is.  So we
need to be clear about how we want releases to work before worrying about
who manages that.

Kind regards,

Paul Angus

paul.an...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue


-Original Message-
From: Alex Hitchins [mailto:a...@alexhitchins.com]
Sent: 30 June 2017 15:05
To: dev@cloudstack.apache.org
Subject: RE: [DISCUSS] - Releases, Project Management & Funding Thereof

I am in complete agreement with you. Also on your other reply regards to
a FT release manager.

If 'we' don't go down this line, more and more people will follow the
Cosmic/Schuberg Philis path or even use Cosmic instead.

I'm encouraged by you

Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Ron Wheeler]

tion, but it was unusable for us historically 
because it required a minimum contribution of 50k, which none of us can afford. 
However, there have been some changes to the board recently which are in our 
favour if we want to put pressure to lower that to say 5-10k.

Even if we do solve for smaller direct contributions, we will have to jump 
through hoops to be able to use those funds for a dedicated release manager. I 
do think this is a possibility if we manage our needs and communications very 
well. I had some preliminary discussions with some apache foundation folks to 
express these specific concerns. I played off the fact that i know they dont 
want to entertain a cloudstack foundation and tried to see if i could get them 
to move on the direct contribution mechanism to make it usable for us, 
specifically with the goal of hiring a full time release manager. I definitely 
had their ear and they acknowledged the problems we are facing (and currently 
discussing).  They expressed concerns about being able to hire someone with the 
direct contributions, but brainstormed a bit to potentially hire an agency who 
actually does the hire and they pay the persons salary through the agency with 
the direct contribution funds.

All to say, there are potential options here, but there be dragons, so we have 
to handle this topic with care.

On Jun 30, 2017 9:12 AM, "Ron Wheeler" <rwhee...@artifact-software.com>
wrote:


https://www.apache.org/foundation/contributing.html says:
"If you have a specific target or project that you wish to directly
support, pleasecontact us <https://www.apache.org/founda
tion/contributing.html#Fundraising>and we will do our best to satisfy
your wishes."

1) Is Apache willing to allow projects to set up their own
foundations? I doubt but someone would need to check this out.
Does the PMC have the project charter or the agreement that was signed
when Cloudstack moved.

2) Has anyone tried to contact Apache about directing support to
Cloudstack.

I am not convinced that lack of paid staff is the issue.
This discussion reminded me of this.
Q: How many psychiatrists does it take to change a lightbulb ?
A: Only one, but the lightbulb must want to change

http://www.lightbulbjokes.com/directory/p.html


Ron


On 30/06/2017 6:48 AM, Alex Hitchins wrote:


As per Giles's comment to the previous thread, I thought I would
start a discussion on the subject to canvas peoples thoughts,
opinions

and fears.

My question for discussion, is there is any mileage in someone
creating a "CloudStack Foundation" as a non-profit entity, funded
largely by key CloudStack players with the sole function of employing
dedicated resource (part or full time) to handle all releases and
other essential 'back office' functions. The idea being it's in
everyone's interest to chip in a little each to fund core project and

release management.

The idea might be utterly irrelevant, pointless and/or straight up daft.
I urge you all to let me know.

Something for you all to think over this weekend.


Alexander Hitchins

E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587

-Original Message-
From: Giles Sirett [mailto:giles.sir...@shapeblue.com]
Sent: 30 June 2017 09:51
To: dev@cloudstack.apache.org
Subject: RE: JIRA - PLEASE READ

All
This thread seems to have turned into 2 quite different discussions:

1. The use (or not) of Jira - which was the original discussion

2. Ways/means of encouraging (and paying for more structured
contributors)

I know that it could be argued that these are related. Could I
suggest opening up a thread on "release and project management and
funding it"  and keeping this thread to the original discussion

(I will weigh in on both of these at some stage)

Kind regards
Giles

giles.sir...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue


-Original Message-
From: Alex Hitchins [mailto:a...@alexhitchins.com]
Sent: 29 June 2017 18:49
To: dev@cloudstack.apache.org
Subject: Re: JIRA - PLEASE READ

If it isn't being treated as a product it will be very impossible to
market it as enterprise ready.

I know we all know this.

Similar sized projects under the Apache banner must have the same
issue, what is the best way to gather experience of these projects?
See how they handle these growing pains.

A cloudstack foundation entity funded by companies earning from
cloudstack seems a good way forward.

Another tuppence, this is getting expensive.



On 29 Jun 2017, at 18:18, Ron Wheeler
<rwhee...@artifact-software.com>

wrote:

I understand that it is a volunteer organization.
I do not know how many (if any) of the committers and PMC members
are funded by their organizations (allowed or ordered to work on
Cloudstack during company time) which is often the way that Apache
projects get staffed.

Clearly it is hard to tell someone who is being fu

Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Ron Wheeler]

een some changes to the board recently which are in our 
favour if we want to put pressure to lower that to say 5-10k.

Even if we do solve for smaller direct contributions, we will have to jump 
through hoops to be able to use those funds for a dedicated release manager. I 
do think this is a possibility if we manage our needs and communications very 
well. I had some preliminary discussions with some apache foundation folks to 
express these specific concerns. I played off the fact that i know they dont 
want to entertain a cloudstack foundation and tried to see if i could get them 
to move on the direct contribution mechanism to make it usable for us, 
specifically with the goal of hiring a full time release manager. I definitely 
had their ear and they acknowledged the problems we are facing (and currently 
discussing).  They expressed concerns about being able to hire someone with the 
direct contributions, but brainstormed a bit to potentially hire an agency who 
actually does the hire and they pay the persons salary through the agency with 
the direct contribution funds.

All to say, there are potential options here, but there be dragons, so we have 
to handle this topic with care.

On Jun 30, 2017 9:12 AM, "Ron Wheeler" <rwhee...@artifact-software.com>
wrote:


https://www.apache.org/foundation/contributing.html says:
"If you have a specific target or project that you wish to directly
support, pleasecontact us <https://www.apache.org/founda
tion/contributing.html#Fundraising>and we will do our best to satisfy
your wishes."

1) Is Apache willing to allow projects to set up their own
foundations? I doubt but someone would need to check this out.
Does the PMC have the project charter or the agreement that was signed
when Cloudstack moved.

2) Has anyone tried to contact Apache about directing support to
Cloudstack.

I am not convinced that lack of paid staff is the issue.
This discussion reminded me of this.
Q: How many psychiatrists does it take to change a lightbulb ?
A: Only one, but the lightbulb must want to change

http://www.lightbulbjokes.com/directory/p.html


Ron


On 30/06/2017 6:48 AM, Alex Hitchins wrote:


As per Giles's comment to the previous thread, I thought I would
start a discussion on the subject to canvas peoples thoughts,
opinions

and fears.

My question for discussion, is there is any mileage in someone
creating a "CloudStack Foundation" as a non-profit entity, funded
largely by key CloudStack players with the sole function of employing
dedicated resource (part or full time) to handle all releases and
other essential 'back office' functions. The idea being it's in
everyone's interest to chip in a little each to fund core project and

release management.

The idea might be utterly irrelevant, pointless and/or straight up daft.
I urge you all to let me know.

Something for you all to think over this weekend.


Alexander Hitchins

E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587

-Original Message-
From: Giles Sirett [mailto:giles.sir...@shapeblue.com]
Sent: 30 June 2017 09:51
To: dev@cloudstack.apache.org
Subject: RE: JIRA - PLEASE READ

All
This thread seems to have turned into 2 quite different discussions:

1. The use (or not) of Jira - which was the original discussion

2. Ways/means of encouraging (and paying for more structured
contributors)

I know that it could be argued that these are related. Could I
suggest opening up a thread on "release and project management and
funding it"  and keeping this thread to the original discussion

(I will weigh in on both of these at some stage)

Kind regards
Giles

giles.sir...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue


-Original Message-
From: Alex Hitchins [mailto:a...@alexhitchins.com]
Sent: 29 June 2017 18:49
To: dev@cloudstack.apache.org
Subject: Re: JIRA - PLEASE READ

If it isn't being treated as a product it will be very impossible to
market it as enterprise ready.

I know we all know this.

Similar sized projects under the Apache banner must have the same
issue, what is the best way to gather experience of these projects?
See how they handle these growing pains.

A cloudstack foundation entity funded by companies earning from
cloudstack seems a good way forward.

Another tuppence, this is getting expensive.



On 29 Jun 2017, at 18:18, Ron Wheeler
<rwhee...@artifact-software.com>

wrote:

I understand that it is a volunteer organization.
I do not know how many (if any) of the committers and PMC members
are funded by their organizations (allowed or ordered to work on
Cloudstack during company time) which is often the way that Apache
projects get staffed.

Clearly it is hard to tell someone who is being funded by a company
to fix a problem or who is working on their own time, to do or not
do something.

On the other hand, the PMC has to  build a commun

Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Ron Wheeler]

1) Are there any good models in the Apache community of projects that 
maintain a quality release process without full-time staff?


2) Are there things that cause most of the grief around releases? 
Anything on the Release Manager's list of aggravations that could be 
eliminated?

Is there a good history of moving from Release Candidates to Releases?
Are there tasks that the RM has to do that should be shifted to the 
community?



Ron

Just provide the rest of the joke.
Q: How many psychiatrists does it take to change a lightbulb ?
A: Only one, but the lightbulb must want to change.
A: None; the bulb will change itself when it is ready.
A: How long have you been having this fantasy ?
A: How many do *you* think it takes?

On 30/06/2017 9:53 AM, Will Stevens wrote:

Yes, Schuberg Philis, a very active community member forked Cosmic off of
CloudStack and has been developing their fork for their needs.

I do think we need to have a more consistent front on this matter. I think
it would make a big difference on the quality, release cadence and
perception of the project.




On Jun 30, 2017 9:48 AM, "Alex Hitchins" <a...@alexhitchins.com> wrote:

Thanks Will,

I understand it's something that comes with a big bag of troublesome
worries.

If this topic comes up again in any discussions, I'd be interested to hear
their thoughts on what I see as the alternative; without a dedicated
RM/PM/Captain, people will fork off CS so they can achieve the same thing,
and CS ultimately looses out long term. I can't remember the name of the
fork, but I think I'm right that a previous large CS contributor/user
forked off as they wanted greater management in the areas we are discussing
here.


Alexander Hitchins

E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587

-Original Message-
From: Will Stevens [mailto:williamstev...@gmail.com]
Sent: 30 June 2017 14:31
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] - Releases, Project Management & Funding Thereof

Apache has been historically against the idea of a cloudstack foundation
and there is a bit of a pandoras box there which we will want to be careful
about opening.

Apache added direct contribution, but it was unusable for us historically
because it required a minimum contribution of 50k, which none of us can
afford. However, there have been some changes to the board recently which
are in our favour if we want to put pressure to lower that to say 5-10k.

Even if we do solve for smaller direct contributions, we will have to jump
through hoops to be able to use those funds for a dedicated release
manager. I do think this is a possibility if we manage our needs and
communications very well. I had some preliminary discussions with some
apache foundation folks to express these specific concerns. I played off
the fact that i know they dont want to entertain a cloudstack foundation
and tried to see if i could get them to move on the direct contribution
mechanism to make it usable for us, specifically with the goal of hiring a
full time release manager. I definitely had their ear and they acknowledged
the problems we are facing (and currently discussing).  They expressed
concerns about being able to hire someone with the direct contributions,
but brainstormed a bit to potentially hire an agency who actually does the
hire and they pay the persons salary through the agency with the direct
contribution funds.

All to say, there are potential options here, but there be dragons, so we
have to handle this topic with care.

On Jun 30, 2017 9:12 AM, "Ron Wheeler" <rwhee...@artifact-software.com>
wrote:


https://www.apache.org/foundation/contributing.html says:
"If you have a specific target or project that you wish to directly
support, pleasecontact us <https://www.apache.org/founda
tion/contributing.html#Fundraising>and we will do our best to satisfy
your wishes."

1) Is Apache willing to allow projects to set up their own
foundations? I doubt but someone would need to check this out.
Does the PMC have the project charter or the agreement that was signed
when Cloudstack moved.

2) Has anyone tried to contact Apache about directing support to
Cloudstack.

I am not convinced that lack of paid staff is the issue.
This discussion reminded me of this.
Q: How many psychiatrists does it take to change a lightbulb ?
A: Only one, but the lightbulb must want to change

http://www.lightbulbjokes.com/directory/p.html


Ron


On 30/06/2017 6:48 AM, Alex Hitchins wrote:


As per Giles's comment to the previous thread, I thought I would
start a discussion on the subject to canvas peoples thoughts, opinions

and fears.

My question for discussion, is there is any mileage in someone
creating a "CloudStack Foundation" as a non-profit entity, funded
largely by key CloudStack players with the sole function of employing
dedicated resource (part or full time) to handle all releases an

Re: JIRA - PLEASE READ

[Ron Wheeler]

it will get better
is by supporting it. And even if I was a coder, "supporting" it with
code

only goes so far.

And as mentioned, we create a CloudStack Foundation that is a 501C
corp so it's a non-profit and tax deductible for people donating.

So the next question is who would we speak with to get this ball
rolling or even a discussion started?

Regards,
Marty Godsey
Principal Engineer
nSource Solutions, LLC

-Original Message-
From: Alex Hitchins [mailto:a...@alexhitchins.com]
Sent: Thursday, June 29, 2017 1:49 PM
To: dev@cloudstack.apache.org
Subject: Re: JIRA - PLEASE READ

If it isn't being treated as a product it will be very impossible to
market it as enterprise ready.

I know we all know this.

Similar sized projects under the Apache banner must have the same
issue, what is the best way to gather experience of these projects?
See how they handle these growing pains.

A cloudstack foundation entity funded by companies earning from
cloudstack seems a good way forward.

Another tuppence, this is getting expensive.




On 29 Jun 2017, at 18:18, Ron Wheeler
<rwhee...@artifact-software.com>

wrote:

I understand that it is a volunteer organization.
I do not know how many (if any) of the committers and PMC members
are

funded by their organizations (allowed or ordered to work on
Cloudstack during company time) which is often the way that Apache
projects get staffed.

Clearly it is hard to tell someone who is being funded by a
company to

fix a problem or who is working on their own time, to do or not do
something.

On the other hand, the PMC has to  build a community culture that
is

good for the project.

That means describing a vision, planning and enforcing a roadmap,
and

maintaining a focused project "marketing" effort.

There is a lot of extremely talented individuals working on
Cloudstack

and it appears to have a very strong and valuable code-base.

To me the key question is about the PMC and the core committers'
ability

to make Cloudstack a "product" that can compete for market share and
acceptance.

Is Cloudstack at a point in its development where it should be
treated

like a product?

- sufficient functionality to compete
- sufficient user base to be a competitor in the market
- production reliability and stability
- business model for supporting companies to justify their
continued support

This may not require more effort but requires different policies
and

different activities.

There has to be someone or a PMC  that can say "No".
- This change can not be included in this release because it will
delay

the release.

- This change adds an unacceptable level of complexity
- This bug fix will have to wait for the next release because it
is too

late to test it and fix the docs.

- This fix breaks the docs
- The release can not be made until this doc is updated.

Does the core group want to make it a competitive product or is it

sufficient for the interested players to continue in its current form?

Ron




On 29/06/2017 9:42 AM, Will Stevens wrote:
I personally don't know how Jira solves any of this, but assuming
it does, fine...

The bigger problem which you have raised is that CloudStack has
zero funding. So we can't hire a project manager, or a release
manager or someone whose job it is to maintain documentation. I
have been trying to find a way to, at the very least, fund a full
time release manager who can focus 100% on the project. As the
release manager for 4.9, I know it is a full time job. I did my
best, but it is a ton of work and is hard to stay on top of.

Everyone contributing to CloudStack is donating their time. They
can't make a living off supporting ACS, so every one is doing
their best with the little time they can take away from their day
job or

their family life.

Yes, having clear guidelines and sticking to them helps, but
without a solid CI infrastructure backing the project and
improved testing and automation, we will always struggles with
release schedules and

such.

I have been involved in this project long enough to know that all
the problems you point out exist, but they are also not easily

solved.

Obviously we have to work with the initiatives we have and take
small steps towards improvement, but we also have to be realistic
with our expectations because we are counting on people's
generosity to move

them forward.

Simplifying moving parts and streamlining the process will lead
to more contribution because there is less barriers to entry.
This one reason why I struggle to see the value in Jira as it is

used today.

I personally don't understand what value it is giving us that the
github PRs and Issues don't solve.

I will remain open minded and will follow along with what people
think is best, but I think it is worth understanding what we are
trying to solve for and simplify our approach in solving it so we
can get better systems in place.



On Jun 29, 2017 9:17 AM, "Ron Wheeler"
<rwhee...

Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Ron Wheeler]

https://www.apache.org/foundation/contributing.html says:
"If you have a specific target or project that you wish to directly 
support, pleasecontact us 
<https://www.apache.org/foundation/contributing.html#Fundraising>and we 
will do our best to satisfy your wishes."


1) Is Apache willing to allow projects to set up their own foundations? 
I doubt but someone would need to check this out.
Does the PMC have the project charter or the agreement that was signed 
when Cloudstack moved.


2) Has anyone tried to contact Apache about directing support to Cloudstack.

I am not convinced that lack of paid staff is the issue.
This discussion reminded me of this.
Q: How many psychiatrists does it take to change a lightbulb ?
A: Only one, but the lightbulb must want to change

http://www.lightbulbjokes.com/directory/p.html


Ron


On 30/06/2017 6:48 AM, Alex Hitchins wrote:

As per Giles's comment to the previous thread, I thought I would start a 
discussion on the subject to canvas peoples thoughts, opinions and fears.

My question for discussion, is there is any mileage in someone creating a 
"CloudStack Foundation" as a non-profit entity, funded largely by key 
CloudStack players with the sole function of employing dedicated resource (part or full 
time) to handle all releases and other essential 'back office' functions. The idea being 
it's in everyone's interest to chip in a little each to fund core project and release 
management.

The idea might be utterly irrelevant, pointless and/or straight up daft. I urge 
you all to let me know.

Something for you all to think over this weekend.


Alexander Hitchins

E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587

-Original Message-
From: Giles Sirett [mailto:giles.sir...@shapeblue.com]
Sent: 30 June 2017 09:51
To: dev@cloudstack.apache.org
Subject: RE: JIRA - PLEASE READ

All
This thread seems to have turned into 2 quite different discussions:

1. The use (or not) of Jira - which was the original discussion

2. Ways/means of encouraging (and paying for more structured contributors)

I know that it could be argued that these are related. Could I suggest opening up a 
thread on "release and project management and funding it"  and keeping this 
thread to the original discussion

(I will weigh in on both of these at some stage)

Kind regards
Giles

giles.sir...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
   
  



-Original Message-
From: Alex Hitchins [mailto:a...@alexhitchins.com]
Sent: 29 June 2017 18:49
To: dev@cloudstack.apache.org
Subject: Re: JIRA - PLEASE READ

If it isn't being treated as a product it will be very impossible to market it 
as enterprise ready.

I know we all know this.

Similar sized projects under the Apache banner must have the same issue, what 
is the best way to gather experience of these projects? See how they handle 
these growing pains.

A cloudstack foundation entity funded by companies earning from cloudstack 
seems a good way forward.

Another tuppence, this is getting expensive.




On 29 Jun 2017, at 18:18, Ron Wheeler <rwhee...@artifact-software.com> wrote:

I understand that it is a volunteer organization.
I do not know how many (if any) of the committers and PMC members are funded by 
their organizations (allowed or ordered to work on Cloudstack during company 
time) which is often the way that Apache projects get staffed.

Clearly it is hard to tell someone who is being funded by a company to fix a 
problem or who is working on their own time, to do or not do something.

On the other hand, the PMC has to  build a community culture that is good for 
the project.
That means describing a vision, planning and enforcing a roadmap, and  maintaining a 
focused project "marketing" effort.

There is a lot of extremely talented individuals working on Cloudstack and it 
appears to have a very strong and valuable code-base.

To me the key question is about the PMC and the core committers' ability to make 
Cloudstack a "product" that can compete for market share and acceptance.

Is Cloudstack at a point in its development where it should be treated like a 
product?
- sufficient functionality to compete
- sufficient user base to be a competitor in the market
- production reliability and stability
- business model for supporting companies to justify their continued
support

This may not require more effort but requires different policies and different 
activities.

There has to be someone or a PMC  that can say "No".
- This change can not be included in this release because it will delay the 
release.
- This change adds an unacceptable level of complexity
- This bug fix will have to wait for the next release because it is too late to 
test it and fix the docs.
- This fix breaks the docs
- The release can not be made until this doc is updated.

Does 

Re: JIRA - PLEASE READ

[Ron Wheeler]

For small fixes that do not affect functionality the value of a JIRA may 
be questioned.


The main advantages that I see:
- if 2 people find the same bug and both fix it without raising a JIRA, 
you may end up with 2 different patches
- if an end-user finds the bug and searches the JIRA to see if it is 
known and scheduled to be fixed, they will find the current status if 
there is a JIRA issue
- end-users may also be willing to fund a fix or commit resources to 
testing it, if the know that it is being worked on.
- often people get attached to their work and if they have invested a 
lot of time in solving the problem without a discussion in the JIRA, 
they will be really upset when the PMC or committers say "no" or "not a 
good solution"
- Googling for a problem will find the JIRA before the release notes are 
ready and the JIRA may have more description of the problem or enhancements.


In any case, there needs to be a policy that the Release Management team 
can depend on.


Perhaps "if it is big enough or sufficiently significant to be included 
in the Release Notes then it should be in the JIRA." might work.
This would allow small fixes and code cleanup to be done quickly with 
minimum overhead.


The policy also should favour the RM team in terms of where the effort 
is allocated.

There is more coding time available than RM time.
Anything that slows the release or adds to the work of the RM, must be 
avoided even if it shifts work to the coders.


Ron


On 29/06/2017 9:42 AM, Will Stevens wrote:

I personally don't know how Jira solves any of this, but assuming it does,
fine...

The bigger problem which you have raised is that CloudStack has zero
funding. So we can't hire a project manager, or a release manager or
someone whose job it is to maintain documentation. I have been trying to
find a way to, at the very least, fund a full time release manager who can
focus 100% on the project. As the release manager for 4.9, I know it is a
full time job. I did my best, but it is a ton of work and is hard to stay
on top of.

Everyone contributing to CloudStack is donating their time. They can't make
a living off supporting ACS, so every one is doing their best with the
little time they can take away from their day job or their family life.

Yes, having clear guidelines and sticking to them helps, but without a
solid CI infrastructure backing the project and improved testing and
automation, we will always struggles with release schedules and such.

I have been involved in this project long enough to know that all the
problems you point out exist, but they are also not easily solved.
Obviously we have to work with the initiatives we have and take small steps
towards improvement, but we also have to be realistic with our expectations
because we are counting on people's generosity to move them forward.

Simplifying moving parts and streamlining the process will lead to more
contribution because there is less barriers to entry. This one reason why I
struggle to see the value in Jira as it is used today. I personally don't
understand what value it is giving us that the github PRs and Issues don't
solve.

I will remain open minded and will follow along with what people think is
best, but I think it is worth understanding what we are trying to solve for
and simplify our approach in solving it so we can get better systems in
place.



On Jun 29, 2017 9:17 AM, "Ron Wheeler" <rwhee...@artifact-software.com>
wrote:


As a real outsider, IMHO Paul is right.

At times it seems that Cloudstack is a coding hobby rather than a project
or a production quality product.

Who decides what goes into a release? How does this affect the release
schedule?
Who is responsible for meeting the "published" roadmap (of which there
seem to be many) of releases?

How is a system admin that is not part of the project supposed to plan for
upgrade windows?
How does one know when a feature, bug fix or release will be available?

How does the PMC  manage function creep  in a release, maintain quality
and consistency, reject changes that hurt the overall vision or add too
much complexity?

No one seems to care about documentation but if someone did, how would
they stop undocumented features or features that contradict the
documentation from being incorporated?
Who makes sure that the documentation is correct at the time of the
release?
Release notes are not much help for someone doing a new install or
evaluating Cloudstack.

Without a JIRA entry, how does an end-user who encounters a problem know
that it has been fixed already in the next release?

Without a JIRA entry, how does the community comment on a proposed change
before it gets coded?

If changes are going to be accepted without a JIRA, is there a definition
of a minor fix that does not require a JIRA?
- does not change functionality?
- only affects an "edge case" or cleans up an exception that is not
properly handled

Re: JIRA - PLEASE READ

[Ron Wheeler]

I understand that it is a volunteer organization.
I do not know how many (if any) of the committers and PMC members are 
funded by their organizations (allowed or ordered to work on Cloudstack 
during company time) which is often the way that Apache projects get 
staffed.


Clearly it is hard to tell someone who is being funded by a company to 
fix a problem or who is working on their own time, to do or not do 
something.


On the other hand, the PMC has to  build a community culture that is 
good for the project.
That means describing a vision, planning and enforcing a roadmap, and  
maintaining a focused project "marketing" effort.


There is a lot of extremely talented individuals working on Cloudstack 
and it appears to have a very strong and valuable code-base.


To me the key question is about the PMC and the core committers' ability 
to make Cloudstack a "product" that can compete for market share and 
acceptance.


Is Cloudstack at a point in its development where it should be treated 
like a product?

- sufficient functionality to compete
- sufficient user base to be a competitor in the market
- production reliability and stability
- business model for supporting companies to justify their continued support

This may not require more effort but requires different policies and 
different activities.


There has to be someone or a PMC  that can say "No".
- This change can not be included in this release because it will delay 
the release.

- This change adds an unacceptable level of complexity
- This bug fix will have to wait for the next release because it is too 
late to test it and fix the docs.

- This fix breaks the docs
- The release can not be made until this doc is updated.

Does the core group want to make it a competitive product or is it 
sufficient for the interested players to continue in its current form?


Ron



On 29/06/2017 9:42 AM, Will Stevens wrote:

I personally don't know how Jira solves any of this, but assuming it does,
fine...

The bigger problem which you have raised is that CloudStack has zero
funding. So we can't hire a project manager, or a release manager or
someone whose job it is to maintain documentation. I have been trying to
find a way to, at the very least, fund a full time release manager who can
focus 100% on the project. As the release manager for 4.9, I know it is a
full time job. I did my best, but it is a ton of work and is hard to stay
on top of.

Everyone contributing to CloudStack is donating their time. They can't make
a living off supporting ACS, so every one is doing their best with the
little time they can take away from their day job or their family life.

Yes, having clear guidelines and sticking to them helps, but without a
solid CI infrastructure backing the project and improved testing and
automation, we will always struggles with release schedules and such.

I have been involved in this project long enough to know that all the
problems you point out exist, but they are also not easily solved.
Obviously we have to work with the initiatives we have and take small steps
towards improvement, but we also have to be realistic with our expectations
because we are counting on people's generosity to move them forward.

Simplifying moving parts and streamlining the process will lead to more
contribution because there is less barriers to entry. This one reason why I
struggle to see the value in Jira as it is used today. I personally don't
understand what value it is giving us that the github PRs and Issues don't
solve.

I will remain open minded and will follow along with what people think is
best, but I think it is worth understanding what we are trying to solve for
and simplify our approach in solving it so we can get better systems in
place.



On Jun 29, 2017 9:17 AM, "Ron Wheeler" <rwhee...@artifact-software.com>
wrote:


As a real outsider, IMHO Paul is right.

At times it seems that Cloudstack is a coding hobby rather than a project
or a production quality product.

Who decides what goes into a release? How does this affect the release
schedule?
Who is responsible for meeting the "published" roadmap (of which there
seem to be many) of releases?

How is a system admin that is not part of the project supposed to plan for
upgrade windows?
How does one know when a feature, bug fix or release will be available?

How does the PMC  manage function creep  in a release, maintain quality
and consistency, reject changes that hurt the overall vision or add too
much complexity?

No one seems to care about documentation but if someone did, how would
they stop undocumented features or features that contradict the
documentation from being incorporated?
Who makes sure that the documentation is correct at the time of the
release?
Release notes are not much help for someone doing a new install or
evaluating Cloudstack.

Without a JIRA entry, how does an end-user who encounters a problem know
that it has been 

Re: JIRA - PLEASE READ

[Ron Wheeler]

As a real outsider, IMHO Paul is right.

At times it seems that Cloudstack is a coding hobby rather than a 
project or a production quality product.


Who decides what goes into a release? How does this affect the release 
schedule?
Who is responsible for meeting the "published" roadmap (of which there 
seem to be many) of releases?


How is a system admin that is not part of the project supposed to plan 
for upgrade windows?

How does one know when a feature, bug fix or release will be available?

How does the PMC  manage function creep  in a release, maintain quality 
and consistency, reject changes that hurt the overall vision or add too 
much complexity?


No one seems to care about documentation but if someone did, how would 
they stop undocumented features or features that contradict the 
documentation from being incorporated?
Who makes sure that the documentation is correct at the time of the 
release?
Release notes are not much help for someone doing a new install or 
evaluating Cloudstack.


Without a JIRA entry, how does an end-user who encounters a problem know 
that it has been fixed already in the next release?


Without a JIRA entry, how does the community comment on a proposed 
change before it gets coded?


If changes are going to be accepted without a JIRA, is there a 
definition of a minor fix that does not require a JIRA?

- does not change functionality?
- only affects an "edge case" or cleans up an exception that is not 
properly handled?

- only improves code readability or future extensibility?
- does not affect documentation?

Apache projects that are popular and enjoy wide support do have strong 
management.


There are other examples where great Apache software is failing to get 
recognized because the PMC is not paying attention to the product 
management side of things.
I use Apache Jackrabbit which is a quality product with a strong 
technical team supporting it.
It has very little following because the documentation and marketing 
collateral is very poor.
It gets by because the audience for it is largely software developers 
who can read code and can test features to work out the functionality.
It would get a lot more attention if they paid attention to the product 
management side of the project.


Cloudstack needs to avoid this situation and unfortunately this takes 
effort and some discipline.



Ron





On 29/06/2017 8:03 AM, Will Stevens wrote:

Why are we still using jira instead of the PRs for that communication? Can
we not use issues in github now instead of jira if someone needs to open an
issue but does not yet have code to contribute. If not, jira could still be
used for that.

I think duplicating data between jira and the PR is kind of pointless. I
feel like the github PRs and the cide going in should be the source of
truth, not a random third party tool.

For the 4.9 release notes, i built a tool to generate the release notes
from the PRs merged in that release. I think that is easier and more
accurate than depending on jira since it does not track the actual code
tree.

Thats my 0.02$.

On Jun 29, 2017 5:25 AM, "Paul Angus" <paul.an...@shapeblue.com> wrote:

Such a view of CloudStack is what holds CloudStack back.
It stops users/operators from having any chance of understanding what
CloudStack does and how it does it.
Code for code's sake is no use to anyone.
Jira is about communication between developers and to everyone else.



Kind regards,

Paul Angus

paul.an...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue




-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
Sent: 29 June 2017 10:14
To: dev <dev@cloudstack.apache.org>
Subject: Re: JIRA - PLEASE READ

On Thu, Jun 29, 2017 at 11:06 AM, Paul Angus <paul.an...@shapeblue.com>
wrote:

+ Release notes will be impossible to create without a proper Jira

history.

And no one will know what has gone into CloudStack.


No they are not mr Grumpy. they should be base on the code anyway, hence on
git, not jira. I do not appose to the use of Jira but it is not required
for good coding practices and as we are not and will not function as a
corporation, jira is an extra for those that grave for it. not a
requirement.

--
Daan



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [proposal] allow mac address to be specified for vm and nic creation

[Ron Wheeler]

Does the PR include the documentation changes required to use it?

Networking is one of the areas where Cloudstack is hard to understand 
and difficult to get setup properly.

Anything that adds another option increases the complexity.

Making Cloudstack more difficult to install in order to circumvent a 
legal agreement seems like a bad idea.


Ron

On 13/06/2017 9:49 AM, Nathan Johnson wrote:

Ron Wheeler <rwhee...@artifact-software.com> wrote:


This would seem to violate the license agreement.
The license is supposed to be tied to specific hardware not a VM.
This sounds like something to be addressed legally rather than technically.


Possibly, but I don’t think that is so much a cloudstack concern as the
users of cloudstack.


It adds more complexity to a part of Cloudstack that already seems to be
a barrier to entry.

This feature is actually to address a current barrier to entry for one of
our customers.

Nathan



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [proposal] allow mac address to be specified for vm and nic creation

[Ron Wheeler]

This would seem to violate the license agreement.
The license is supposed to be tied to specific hardware not a VM.
This sounds like something to be addressed legally rather than technically.

It adds more complexity to a part of Cloudstack that already seems to be 
a barrier to entry.


Ron

On 13/06/2017 9:25 AM, Nathan Johnson wrote:

The title pretty much says it all.  Currently mac addresses are
automagically generated based on the guru that is responsible for the
network type.  This would allow that behavior to be overridden by the API
on deployVirtualMachine and addNicToVirtualMachine .  One potential issue
is that if the specified mac address was in the same range of potentially
auto-generated mac addresses, there could be a collision, however this
could be pretty easily mitigated by just testing for a mac already defined
by that network and asking for the next
getNextAvailableMacAddressInNetwork.  The primary driver for this is to be
able to import VMs from other hypervisors / environments where the mac
address of the guest would need to stay the same, for instance if a piece
of commercial software was tied to the MAC address.  I have a working PR
here:

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

minus the logic around avoiding collisions where manually specified mac
addresses for a network in the same range as those generated by the guru,
and the guru generating a collision sometime later.

Nathan Johnson
R Engineer
Education Networks of America




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [DISCUSS] API versioning

[Ron Wheeler]

I suppose that in openAPI, one would have to identify {/diskofferingid, 
zoneid//and ///snapshotid/} /as parameters and use the parameter 
description to explain when each parameter is used.


Rough outline

swagger: '2.0'
info:
  version: 5.0.0
  title: Volume Management Service
  description: Manage volumes
schemes:
  - https
host: cloudstack.apache.org
basePath: /manager
paths:
  /createVolume:
   post:
  summary: Creates a volume
  description: Creates a volume based on ... or from a snapshot
  parameters:
   - name: diskofferingid
 in: query
 description: Offering id. Required with zoneid  when .
 type: integer
   - name: zoneid
 in: query
 description: Zone id. Required with diskofferingid when 
creating...

 type: integer
   - name: snapshotid
 in: query
 description: Snapshot id. Used  when creating a volume from a 
snapshot..

 type: integer
  responses:
200:
  description: Volume created successfully
401:
  description: Not authorized. User unknown.
403:
  description: Insufficient privileges.
406:
  description: Parameters failed validation.
408:
  description: Request timeout
500:
  description: Internal server Error

This would seem to be more or less analogous to what the code actually 
does.
It accepts any set of parameters initially and from the context, decides 
which ones are required and which ones are optional and which ones are 
not acceptable.


Perhaps not a perfect solution but certainly goes a long way to getting 
a consistent and somewhat rigorous definition of the API.
Depending on the quality and completeness of the descriptions, someone 
reading the openAPI reports would have a pretty good idea about how to 
use the createVolume service.


Ron

On 06/06/2017 11:44 AM, Syed Ahmed wrote:
The interesting thing about Cloudstack's API is that not all 
parameters are required and based on what is being used, a set of 
parameters is required. For example: take the createVolume API.


If you are creating a new volume, the required args are: 
{/diskofferingid, zoneid//} /and if you use a snapshot to create the 
volume, the required args are {/snapshotid/}//This kind of dependency 
is very hard to represent in Swagger. I haven't found any tool that 
correctly represents the relation between different args as yet. Do 
you guys have any idea?


On Mon, Jun 5, 2017 at 2:23 PM, Ron Wheeler 
<rwhee...@artifact-software.com 
<mailto:rwhee...@artifact-software.com>> wrote:


Are you thinking of using OpenAPI(Swagger) to do the documentation?

Ron

On 05/06/2017 10:14 AM, Rafael Weingärtner wrote:

This might be a good excuse for an ACS 5.0! Maybe with some
other additions
such as the support for OASIS CAMP or TOSCA?

It would be interesting to have a ROADMAP with these
desires/wishes.

On Mon, Jun 5, 2017 at 8:52 AM, Simon Weller
<swel...@ena.com.invalid>
wrote:

+1. Echoing what Rohit pointed out, we have a lot of
cleanup to do :-) It
certainly makes it a lot easier though when you're not
breaking
compatibility with existing code.


From: Rohit Yadav <rohit.ya...@shapeblue.com
<mailto:rohit.ya...@shapeblue.com>>
Sent: Monday, June 5, 2017 4:04 AM
To: dev@cloudstack.apache.org
<mailto:dev@cloudstack.apache.org>
Subject: Re: [DISCUSS] API versioning

+1 Good idea, though bear in mind there are 500+ APIs with no
modern-RESTful-standardization, a lot of work.


Regards.


From: Nitin Kumar Maharana
<nitinkumar.mahar...@accelerite.com
<mailto:nitinkumar.mahar...@accelerite.com>>
Sent: 05 June 2017 12:37:24
To: dev@cloudstack.apache.org
<mailto:dev@cloudstack.apache.org>
Subject: Re: [DISCUSS] API versioning

This looks good. +1

rohit.ya...@shapeblue.com <mailto:rohit.ya...@shapeblue.com>
www.shapeblue.com
<http://www.shapeblue.com><http://www.shapeblue.com
<http://www.shapeblue.com>>
[http://shapeblue.com/wp-content/uploads/2014/03/sungardonline1.jpg

<http://shapeblue.com/wp-content/uploads/2014/03/sungardonline1.jpg>]<
http://www.shapeblue.com/>

Shapeblue - The CloudStack
Company<http://www.shapeblue.com/ <http://www.shapeblue.com/>>
www.shapeblue.com <http://www.shapeblue.com>
The city of Prague was the venue for the spring meeting of
 

Re: [DISCUSS] API versioning

[Ron Wheeler]

Are you thinking of using OpenAPI(Swagger) to do the documentation?

Ron

On 05/06/2017 10:14 AM, Rafael Weingärtner wrote:

This might be a good excuse for an ACS 5.0! Maybe with some other additions
such as the support for OASIS CAMP or TOSCA?

It would be interesting to have a ROADMAP with these desires/wishes.

On Mon, Jun 5, 2017 at 8:52 AM, Simon Weller <swel...@ena.com.invalid>
wrote:


+1. Echoing what Rohit pointed out, we have a lot of cleanup to do :-) It
certainly makes it a lot easier though when you're not breaking
compatibility with existing code.


From: Rohit Yadav <rohit.ya...@shapeblue.com>
Sent: Monday, June 5, 2017 4:04 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] API versioning

+1 Good idea, though bear in mind there are 500+ APIs with no
modern-RESTful-standardization, a lot of work.


Regards.


From: Nitin Kumar Maharana <nitinkumar.mahar...@accelerite.com>
Sent: 05 June 2017 12:37:24
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] API versioning

This looks good. +1

rohit.ya...@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
[http://shapeblue.com/wp-content/uploads/2014/03/sungardonline1.jpg]<
http://www.shapeblue.com/>

Shapeblue - The CloudStack Company<http://www.shapeblue.com/>
www.shapeblue.com
The city of Prague was the venue for the spring meeting of the Cloudstack
European user group. There was



53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue




On 04-Jun-2017, at 2:34 PM, Rene Moser <m...@renemoser.net> wrote:

Hi

I recently developed ansible modules for the ACL API and ... found this
has a really inconsistent API naming. E.g.

createNetworkACL <<-- this creates an ACL rule
createNetworkACLList <<-- this create the ACL

updateNetworkACLItem <<-- this updates an ACL rule
updateNetworkACLList <<-- this updates the ACL

My first thoughs was, someone has to fix this, like

createNetworkAclRule <<-- this create the ACL rule
createNetworkAcl <<-- this creates an ACL

updateNetworkAclRule <<-- this updates the ACL rule
updateNetworkAcl <<-- this updates an ACL

But how without breaking the API for backwards compatibility? I know a
few other places where the API has inconsistent namings. Fixing the API
but in a controlled way? What about by adding a version to the API?

I would like to introduce a API versioning to cloudstack: The current
API would be frozen into verison v1. The new API will have v2. The
versioned API has the URL scheme:

/client/api/

The current API would be /client/api/v1 and the /client/api would be an
alias for v1. This ensures backwards compatibility.

This would allow us to deprecate and change APIs.

Any thoughts?







DISCLAIMER
==
This e-mail may contain privileged and confidential information which is
the property of Accelerite, a Persistent Systems business. It is intended
only for the use of the individual or entity to which it is addressed. If
you are not the intended recipient, you are not authorized to read, retain,
copy, print, distribute or use this message. If you have received this
communication in error, please notify the sender and delete all copies of
this message. Accelerite, a Persistent Systems business does not accept any
liability for virus infected mails.






--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [DISCUSS] API versioning

[Ron Wheeler]

Please do not make any more roadmaps!
There are more than enough already and many include old promises about 
updates that will be done on the page.


https://cwiki.apache.org/confluence/display/CLOUDSTACK/Roadmap
https://cwiki.apache.org/confluence/display/CLOUDSTACK/2015+Plan
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases
https://cwiki.apache.org/confluence/display/CLOUDSTACK/%5BPROPOSAL%5D+2016-2017+Release+Cycle+and+Calendar
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases+in+Progress
There may be more. I only spent 2 minutes to find these.

Can we get rid of all of these that are not going to be kept up to date?
I know that one can not permanently delete any wiki page but at least 
get them off the menu and not visible to people wanting to gauge the 
state of the project.



Would it be helpful to have a vote about which one to keep and bring up 
to date?


Ron



On 05/06/2017 10:14 AM, Rafael Weingärtner wrote:

This might be a good excuse for an ACS 5.0! Maybe with some other additions
such as the support for OASIS CAMP or TOSCA?

It would be interesting to have a ROADMAP with these desires/wishes.

On Mon, Jun 5, 2017 at 8:52 AM, Simon Weller <swel...@ena.com.invalid>
wrote:


+1. Echoing what Rohit pointed out, we have a lot of cleanup to do :-) It
certainly makes it a lot easier though when you're not breaking
compatibility with existing code.


From: Rohit Yadav <rohit.ya...@shapeblue.com>
Sent: Monday, June 5, 2017 4:04 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] API versioning

+1 Good idea, though bear in mind there are 500+ APIs with no
modern-RESTful-standardization, a lot of work.


Regards.


From: Nitin Kumar Maharana <nitinkumar.mahar...@accelerite.com>
Sent: 05 June 2017 12:37:24
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] API versioning

This looks good. +1

rohit.ya...@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
[http://shapeblue.com/wp-content/uploads/2014/03/sungardonline1.jpg]<
http://www.shapeblue.com/>

Shapeblue - The CloudStack Company<http://www.shapeblue.com/>
www.shapeblue.com
The city of Prague was the venue for the spring meeting of the Cloudstack
European user group. There was



53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue




On 04-Jun-2017, at 2:34 PM, Rene Moser <m...@renemoser.net> wrote:

Hi

I recently developed ansible modules for the ACL API and ... found this
has a really inconsistent API naming. E.g.

createNetworkACL <<-- this creates an ACL rule
createNetworkACLList <<-- this create the ACL

updateNetworkACLItem <<-- this updates an ACL rule
updateNetworkACLList <<-- this updates the ACL

My first thoughs was, someone has to fix this, like

createNetworkAclRule <<-- this create the ACL rule
createNetworkAcl <<-- this creates an ACL

updateNetworkAclRule <<-- this updates the ACL rule
updateNetworkAcl <<-- this updates an ACL

But how without breaking the API for backwards compatibility? I know a
few other places where the API has inconsistent namings. Fixing the API
but in a controlled way? What about by adding a version to the API?

I would like to introduce a API versioning to cloudstack: The current
API would be frozen into verison v1. The new API will have v2. The
versioned API has the URL scheme:

/client/api/

The current API would be /client/api/v1 and the /client/api would be an
alias for v1. This ensures backwards compatibility.

This would allow us to deprecate and change APIs.

Any thoughts?







DISCLAIMER
==
This e-mail may contain privileged and confidential information which is
the property of Accelerite, a Persistent Systems business. It is intended
only for the use of the individual or entity to which it is addressed. If
you are not the intended recipient, you are not authorized to read, retain,
copy, print, distribute or use this message. If you have received this
communication in error, please notify the sender and delete all copies of
this message. Accelerite, a Persistent Systems business does not accept any
liability for virus infected mails.






--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Release Cycle and Calendar

[Ron Wheeler]

https://cwiki.apache.org/confluence/display/CLOUDSTACK/%5BPROPOSAL%5D+2016-2017+Release+Cycle+and+Calendar 
is an interesting page that needs to be updated or removed.


Has the proposal been accepted?

Are all of the dates realistic now?

What dates were met?

Could it be expanded to include the actual dates?


https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases+in+Progress 
looks like it should be updated.


https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS as well

Ron


--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Miami CCC '17 Roundtable/Hackathon Summary

[Ron Wheeler]

; wrote:

 Hi everyone,


 During the CCC last week in Miami, we held a roundtable/hackathon
to discuss some of the major areas the community would like to focus
more attention.


 The discussions were passionate and were mainly focused around
networking and our current use of our home-spun Virtual Router.


 For most of the us, the VR has become a challenging beast, mainly
due to how difficult it is to end-to-end test for new releases.

 Quite often PRs are pushed that fix an issue on one feature set,
but break another unintentionally. This has a great deal to do with
how inter-mingled all the features are currently.


 We floated some ideas related to short term VR fixes in order to
make it more modular, as well as API driven, rather than the currently
SSH JSON injections.

 A number of possible alternatives were also brought up to see what
VR feature coverage could be handled by other virtual appliances
currently out on the market.


 These included (but not limited to):


 VyOS (current PR out there for integration via a plugin – thanks
Matthew!)

 Microtek (Commerical)

 Openswitch/Flexswitch

 Cloud Router


 The second major topic of the day was related to how we want to
integrate networking moving forward.


 A fair number of individuals felt that we shouldn't be focusing so
much on integrating network functions, but relying on other network
orchestrators to hand this.

 It was also noted that what draws a lot of people to ACS is the
fact we have a VR and do provide these functions out of the box.


 We discussed how we could standardize the network sub system to
use some sort of queuing bus to make it easier for others projects to
integrate their solutions.

 The current plugin implementation is fairly complex and often
other projects (or commercial entities) put it into the too hard
basket, until someone either does it themselves or is willing to pay for the 
development.

 Most also felt it was important to maintain a default network
function that works out of the box so that the complexity of a full
orchestrator could be avoided if not needed.


 I'm sure I've missed some key points, so hopefully this starts a
discussion with the entire community of where we focused next.


 Thanks to all those that participated on Tuesday afternoon.


 - Si




daan.hoogl...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue








--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [QUESTION] Upgrade path to JDK8

[Ron Wheeler]

7 at 1:15 PM, Wei ZHOU <

ustcweiz...@gmail.com

wrote:

We've tested management server 4.7.1 with ubuntu

16.04/openjdk8

and

systemvm 4.6 with debian7/openjdk7.
The systemvms (ssvm, cpvm) work fine.

I agree we need consider the openjdk upgrade in systemvm

template.

-Wei

2017-02-20 18:15 GMT+01:00 Will Stevens <

wstev...@cloudops.com

:

Regarding my question. Is it because of the version of Java

that

the

systemvm.iso is built on?

On Feb 20, 2017 11:58 AM, "Will Stevens" <

wstev...@cloudops.com

wrote:

A question that is hidden in here is:
- Why does the JDK version on the management server have to

match

the

JDK

version of the System VM?

*Will STEVENS*
Lead Developer

<https://goo.gl/NYZ8KK>

On Mon, Feb 20, 2017 at 11:50 AM, Pierre-Luc Dion <

pd...@cloudops.com>

wrote:


Hi,

In the context of deployment of CloudStack with VPCs,
What will happen to a cloud when upgrading to 4.10 that

now

use

jdk8?

Does upgrading the management-server to 4.10 jdk8 and then

keep

the

old

VRs
run for a while that run on JDK7 will still work ?

Because If we upgrade the management-server to jdk8, we

need

to

keep

VR

to

work until they get upgraded but we can't force an upgrade

of

VR

just

because the management-server is now using JDK8.

Thanks,








--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [QUESTION] Upgrade path to JDK8

[Ron Wheeler]

Are any Java enhancements being added to common libraries that would 
force the Client side to have to run Java 8?
Would running Java 7 cause any library to need to be available in 2 
versions?


Ron

On 20/02/2017 11:58 AM, Will Stevens wrote:

A question that is hidden in here is:
- Why does the JDK version on the management server have to match the JDK
version of the System VM?

*Will STEVENS*
Lead Developer

<https://goo.gl/NYZ8KK>

On Mon, Feb 20, 2017 at 11:50 AM, Pierre-Luc Dion <pd...@cloudops.com>
wrote:


Hi,

In the context of deployment of CloudStack with VPCs,
What will happen to a cloud when upgrading to 4.10 that now use jdk8?

Does upgrading the management-server to 4.10 jdk8 and then keep the old VRs
run for a while that run on JDK7 will still work ?

Because If we upgrade the management-server to jdk8, we need to keep VR to
work until they get upgraded but we can't force an upgrade of VR just
because the management-server is now using JDK8.

Thanks,




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Starting jetty on another port

[Ron Wheeler]

Probably a question that could be asked on the user mailing list.

On 18/07/2016 3:41 PM, Syed Mushtaq wrote:

Hi,

Is there a way to start Jetty on a port other than :8080? I've tried with

mvn -pl :cloud-client-ui jetty:run -Djetty.port=8081

and it did not work. I need this because the machine where I am doing my
dev is alreay
running a service on port 8080 and I can't change that.

-Syed



What error did you get?

Are you sure that 8081 is free?

Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: CloudStack Logo Font

[Ron Wheeler]

I incorporated the first three as links on the documentation page.
They fit well into the Marketing section but do have information that 
might be useful to the documentation effort.


The 4th link does not seem to be related to documentation and seems to 
stand on its own very well where it is in the Marketing section.


Thanks for pointing these out.

Ron


On 20/06/2016 12:34 PM, Will Stevens wrote:

Currently the main resources are:
https://cloudstack.apache.org/trademark-guidelines.html
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Event+Resources+and+Templates
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Graphics+and+Resources
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Social+Media+Guidelines

Unfortunately the information is spread out all over the place and is hard
to understand.  I will be looking to clean up the details and add the new
content we vote on (when ready).

*Will STEVENS*
Lead Developer

*CloudOps* *| *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_

On Mon, Jun 20, 2016 at 12:30 PM, Ron Wheeler <
rwhee...@artifact-software.com> wrote:


Please do not forget to add the sources to the Cloudsack documentation on
git.

If you send me the sources and the actual image, I will add them to the
new consolidated docs.

Still looking for the sources for all of the other images in the current
docs.
If there are any comments that you think need to be known by future VPs,
the wiki is a good place to put them.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Documentation+resources

Ron

On 20/06/2016 12:06 PM, Will Stevens wrote:


Thanks for the responses.  This information is really helpful for the
'powered by' logo variation conversation and such.

I am trying to get all this type of branding/marketing information
together
so it is easier for people/organizations to use the brand and the usage of
the brand is consistent everywhere.  I probably won't have anything
interesting for a while because I have so many other things going on, but
I
wanted to start collecting relevant information.

Thanks...

*Will STEVENS*
Lead Developer

*CloudOps* *| *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_

On Mon, Jun 20, 2016 at 11:13 AM, Daniel Gruno <humbed...@apache.org>
wrote:



On 2016-06-17 17:12 (+0200), Will Stevens <williamstev...@gmail.com>
wrote:


Does anyone know what the font is that was used to create the
apachecloudstack logo as well as the font used for the tagline?


The logo is using Avenir Black from Adobe, I believe...

I have not been able to find those details.  Anyone???

Thanks,

Will



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: CloudStack Logo Font

[Ron Wheeler]

Please do not forget to add the sources to the Cloudsack documentation 
on git.


If you send me the sources and the actual image, I will add them to the 
new consolidated docs.


Still looking for the sources for all of the other images in the current 
docs.
If there are any comments that you think need to be known by future VPs, 
the wiki is a good place to put them.
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Documentation+resources 



Ron

On 20/06/2016 12:06 PM, Will Stevens wrote:

Thanks for the responses.  This information is really helpful for the
'powered by' logo variation conversation and such.

I am trying to get all this type of branding/marketing information together
so it is easier for people/organizations to use the brand and the usage of
the brand is consistent everywhere.  I probably won't have anything
interesting for a while because I have so many other things going on, but I
wanted to start collecting relevant information.

Thanks...

*Will STEVENS*
Lead Developer

*CloudOps* *| *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_

On Mon, Jun 20, 2016 at 11:13 AM, Daniel Gruno <humbed...@apache.org> wrote:



On 2016-06-17 17:12 (+0200), Will Stevens <williamstev...@gmail.com>
wrote:

Does anyone know what the font is that was used to create the
apachecloudstack logo as well as the font used for the tagline?

The logo is using Avenir Black from Adobe, I believe...


I have not been able to find those details.  Anyone???

Thanks,

Will




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Roadmap for 4.x and 5.0

[Ron Wheeler]

I added 2 columns to 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Roadmap to 
facilitate the discussion.


"Last Updated" can give the reader some idea about the currency of the 
information.
"Comments" should allow some light discussion. Heavy discussion could be 
a good indication that the item needs its own child page.


Please have a look to see if any of these tasks are yours and bring them 
up to date.
If you think that a task has died, please at least add a comment or if 
you are certain, delete the task.


Feel free to remove my questions from the comment field if you update 
the task status.


The title of the page is Roadmap and it starts out "This is the roadmap 
for CloudStack code development." which implies that there is some level 
of shared commitment to implement these things within a timeframe that 
would match users expectations for "soon".


A lot of the items do not have JIRAs.
Does this mean that they are so far out in the future that they are not 
really relevant to a roadmap and should be moved to a "wishlist"?


The title also gives the expectation that this covers all of the major 
enhancements in the foreseeable future.

Anything that is being worked on for 4.10 should be on this list by now.

Ron


On 17/06/2016 10:25 AM, Ron Wheeler wrote:


https://cwiki.apache.org/confluence/display/CLOUDSTACK/Roadmap

Needs updating. Some of the work must have been completed since it is 
slotted for 4.6.


Perhaps this is the page to start laying out the "new" release 
protocol and to start to collect the tasks for 4.10 and 4.11


It would also be a good place to collect ideas for 5.0 so that we can 
see what the proposed release numbering and delivery schedule actually 
means in terms of delivery of functionality.


The mailing list discussion has been pretty robust and a lot of 
writing has been done that deserves a more permanent home and some 
more concrete descriptions of proposed work.


Ron




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: 4.9/master Testing Coordination

[Ron Wheeler]

Would it make sense to use the wiki for tracking this?

Ron

On 17/06/2016 2:56 PM, John Burwell wrote:

All,

It is a bit lo-fi, but if you are testing master in preparation for the 4.9 RC, 
could you please share information about the configurations you testing (e.g. 
hypervisors, storage backends, network configurations, etc)?  Any test results 
could also be helpful.  The hope is to reduce duplication of effort and 
understand how much of the system has been covered.

Thanks,
-John
john.burw...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Missing Apache Board Reports

[Ron Wheeler]

Will,

Perfect.

Can you delete this page.
I do not have permission to do this.

Thanks.
Ron

On 17/06/2016 10:21 AM, Will Stevens wrote:

I don't think it is useful to duplicate this information in our wiki.  If
people want to see these reports they should check them at the official ASF
location.

https://whimsy.apache.org/board/minutes/CloudStack.html

*Will STEVENS*
Lead Developer

*CloudOps* *| *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_

On Fri, Jun 17, 2016 at 10:13 AM, Ron Wheeler <
rwhee...@artifact-software.com> wrote:


https://cwiki.apache.org/confluence/display/CLOUDSTACK/Board+Reports
shows that no reports have been provided since 2014.

Can the person responsible for submitting the reports to Apache, please
update these pages.

Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Roadmap for 4.x and 5.0

[Ron Wheeler]

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Roadmap

Needs updating. Some of the work must have been completed since it is 
slotted for 4.6.


Perhaps this is the page to start laying out the "new" release protocol 
and to start to collect the tasks for 4.10 and 4.11


It would also be a good place to collect ideas for 5.0 so that we can 
see what the proposed release numbering and delivery schedule actually 
means in terms of delivery of functionality.


The mailing list discussion has been pretty robust and a lot of writing 
has been done that deserves a more permanent home and some more concrete 
descriptions of proposed work.


Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Maintenance guide needs updating

[Ron Wheeler]

https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Maintainers+Guide+-+Draft


Is this still a draft?

Can everyone look at the list of maintainers for each area and add any 
people updates or create new areas.



Ron


--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Missing Apache Board Reports

[Ron Wheeler]

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Board+Reports 
shows that no reports have been provided since 2014.


Can the person responsible for submitting the reports to Apache, please 
update these pages.


Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Delete obsolete stuff from the wiki

[Ron Wheeler]

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Graduation looks 
like it could go.


Anyone object if I delete it?

Ron


--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102