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

Reply via email to