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,
<rwhee...@artifact-software.com.invalid> 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 <rohit.ya...@shapeblue.com>
Sent: 01 July 2020 13:04
To: dev@cloudstack.apache.org <dev@cloudstack.apache.org>;
us...@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 <abhishek.ku...@shapeblue.com>
Sent: Wednesday, July 1, 2020 11:14
To: dev@cloudstack.apache.org <dev@cloudstack.apache.org>;
us...@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)
at
org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:122)
at
org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:894)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:553)
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.<init>(CloudStackSpringContext.java:57)
at
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.<init>(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
--
Ron Wheeler
Artifact Software
438-345-3369
rwhee...@artifact-software.com
