You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Abhishek Kumar <Ab...@shapeblue.com> on 2020/07/01 05:44:20 UTC
[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.Kumar@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
Re: [DISCUSS] Management server default port conflict
Posted by Wei ZHOU <us...@gmail.com>.
if cockpit uses 9090, then stop it, otherwise not stop it?
On Wed, 1 Jul 2020 at 10:18, Andrija Panic <an...@gmail.com> wrote:
> Besides updating the documentation, I'm tempted to even explicitly add a
> command that would disable the cockpit service on boot and stop it (and
> echo the message that we've disabled it...)- as part of the
> cloudstack-setup-management or similar.
> Otherwise, novice users will certainly stumble sooner or later on this
> issue.
>
>
> On Wed, 1 Jul 2020 at 09:34, Rohit Yadav <ro...@shapeblue.com>
> wrote:
>
> > 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 <Ab...@shapeblue.com>
> > Sent: Wednesday, July 1, 2020 11:14
> > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>;
> > users@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.Kumar@shapeblue.com
> > www.shapeblue.com<http://www.shapeblue.com>
> > 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> > @shapeblue
> >
> >
> >
> >
> > rohit.yadav@shapeblue.com
> > www.shapeblue.com
> > 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> > @shapeblue
> >
> >
> >
> >
>
> --
>
> Andrija Panić
>
Re: [DISCUSS] Management server default port conflict
Posted by Andrija Panic <an...@gmail.com>.
Besides updating the documentation, I'm tempted to even explicitly add a
command that would disable the cockpit service on boot and stop it (and
echo the message that we've disabled it...)- as part of the
cloudstack-setup-management or similar.
Otherwise, novice users will certainly stumble sooner or later on this
issue.
On Wed, 1 Jul 2020 at 09:34, Rohit Yadav <ro...@shapeblue.com> wrote:
> 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 <Ab...@shapeblue.com>
> Sent: Wednesday, July 1, 2020 11:14
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>;
> users@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.Kumar@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
> rohit.yadav@shapeblue.com
> www.shapeblue.com
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
--
Andrija Panić
Re: [DISCUSS] Management server default port conflict
Posted by Sven Vogel <S....@ewerk.com>.
I see the same like Paul and a fast fail would be nice. Cheers
__
Sven Vogel
Lead Cloud Solution Architect
EWERK DIGITAL GmbH
Br?hl 24, D-04109 Leipzig
P +49 341 42649 - 99
F +49 341 42649 - 98
S.Vogel@ewerk.com
www.ewerk.com
Gesch?ftsf?hrer:
Dr. Erik Wende, Hendrik Schubert, Tassilo M?schke
Registergericht: Leipzig HRB 9065
Support:
+49 341 42649 555
Zertifiziert nach:
ISO/IEC 27001:2013
DIN EN ISO 9001:2015
DIN ISO/IEC 20000-1:2011
ISAE 3402 Typ II Assessed
EWERK-Blog<https://blog.ewerk.com/> | LinkedIn<https://www.linkedin.com/company/ewerk-group> | Xing<https://www.xing.com/company/ewerk> | Twitter<https://twitter.com/EWERK_Group> | Facebook<https://de-de.facebook.com/EWERK.IT/>
Ausk?nfte und Angebote per Mail sind freibleibend und unverbindlich.
Disclaimer Privacy:
Der Inhalt dieser E-Mail (einschlie?lich etwaiger beigef?gter Dateien) ist vertraulich und nur f?r den Empf?nger bestimmt. Sollten Sie nicht der bestimmungsgem??e Empf?nger sein, ist Ihnen jegliche Offenlegung, Vervielf?ltigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem Fall unverz?glich den Absender und l?schen Sie die E-Mail (einschlie?lich etwaiger beigef?gter Dateien) von Ihrem System. Vielen Dank.
The contents of this e-mail (including any attachments) are confidential and may be legally privileged. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system. Thank you.
________________________________
Von: Ron Wheeler <rw...@artifact-software.com.INVALID>
Gesendet: Thursday, July 2, 2020 1:06:20 PM
An: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Betreff: Re: [DISCUSS] Management server default port conflict
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.angus@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
> -----Original Message-----
> From: Wei ZHOU <us...@gmail.com>
> 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 <rw...@artifact-software.com.invalid> 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,
>>> <rw...@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 <ro...@shapeblue.com>
>>>>> Sent: 01 July 2020 13:04
>>>>> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>;
>>>> users@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 <Ab...@shapeblue.com>
>>>>> Sent: Wednesday, July 1, 2020 11:14
>>>>> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>;
>>>> users@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.w
>> ith(CloudStackExtendedLifeCycle.java:114)
>>>>> at
>> org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.wit
>> h(CloudStackExtendedLifeCycle.java:153)
>>>>> at
>> org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.con
>> figure(CloudStackExtendedLifeCycle.java:110)
>>>>> at
>> org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.sta
>> rt(CloudStackExtendedLifeCycle.java:55)
>>>>> at
>> org.springframework.context.support.DefaultLifecycleProcessor.doStart(
>> DefaultLifecycleProcessor.java:182)
>>>>> at
>> org.springframework.context.support.DefaultLifecycleProcessor.access$2
>> 00(DefaultLifecycleProcessor.java:53)
>>>>> at
>> org.springframework.context.support.DefaultLifecycleProcessor$Lifecycl
>> eGroup.start(DefaultLifecycleProcessor.java:360)
>>>>> at
>> org.springframework.context.support.DefaultLifecycleProcessor.startBea
>> ns(DefaultLifecycleProcessor.java:158)
>>>>> at
>> org.springframework.context.support.DefaultLifecycleProcessor.onRefres
>> h(DefaultLifecycleProcessor.java:122)
>>>>> at
>> org.springframework.context.support.AbstractApplicationContext.finishR
>> efresh(AbstractApplicationContext.java:894)
>>>>> at
>> org.springframework.context.support.AbstractApplicationContext.refresh
>> (AbstractApplicationContext.java:553)
>>>>> at
>> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
>> Set.loadContext(DefaultModuleDefinitionSet.java:144)
>>>>> at
>> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
>> Set$2.with(DefaultModuleDefinitionSet.java:121)
>>>>> at
>> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
>> Set.withModule(DefaultModuleDefinitionSet.java:244)
>>>>> at
>> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
>> Set.withModule(DefaultModuleDefinitionSet.java:249)
>>>>> at
>> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
>> Set.withModule(DefaultModuleDefinitionSet.java:249)
>>>>> at
>> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
>> Set.withModule(DefaultModuleDefinitionSet.java:232)
>>>>> at
>> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
>> Set.loadContexts(DefaultModuleDefinitionSet.java:116)
>>>>> at
>> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
>> Set.load(DefaultModuleDefinitionSet.java:78)
>>>>> at
>> org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory.
>> loadModules(ModuleBasedContextFactory.java:37)
>>>>> at
>> org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.in
>> it(CloudStackSpringContext.java:70)
>>>>> at
>> org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.<i
>> nit>(CloudStackSpringContext.java:57)
>>>>> at
>> org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.<i
>> nit>(CloudStackSpringContext.java:61)
>>>>> at
>> org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListene
>> r.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(ContextHa
>> ndler.java:889)
>>>>> at
>> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletCo
>> ntextHandler.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(ServletContext
>> Handler.java:275)
>>>>> at
>>>> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:5
>>>> 24)
>>>>> at
>> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeC
>> ycle.java:72)
>>>>> at
>> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLif
>> eCycle.java:169)
>>>>> at
>> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerL
>> ifeCycle.java:110)
>>>>> at
>> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandl
>> er.java:97)
>>>>> at
>> org.eclipse.jetty.server.handler.gzip.GzipHandler.doStart(GzipHandler.
>> java:425)
>>>>> at
>> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeC
>> ycle.java:72)
>>>>> at
>> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLif
>> eCycle.java:169)
>>>>> at
>> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerL
>> ifeCycle.java:117)
>>>>> at
>> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandl
>> er.java:97)
>>>>> at
>> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeC
>> ycle.java:72)
>>>>> at
>> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLif
>> eCycle.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.Kumar@shapeblue.com
>>>>> www.shapeblue.com<http://www.shapeblue.com>
>>>>> 3 London Bridge Street, 3rd floor, News Building, London SE1
>>>>> 9SGUK @shapeblue
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> rohit.yadav@shapeblue.com
>>>>> www.shapeblue.com<http://www.shapeblue.com>
>>>>> 3 London Bridge Street, 3rd floor, News Building, London SE1
>>>>> 9SGUK @shapeblue
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Abhishek.Kumar@shapeblue.com
>>>>> www.shapeblue.com<http://www.shapeblue.com>
>>>>> 3 London Bridge Street, 3rd floor, News Building, London SE1
>>>>> 9SGUK @shapeblue
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Ron Wheeler
>>>> Artifact Software
>>>> 438-345-3369
>>>> rwheeler@artifact-software.com
>>>>
>>>>
>> --
>> Ron Wheeler
>> Artifact Software
>> 438-345-3369
>> rwheeler@artifact-software.com
>>
>>
--
Ron Wheeler
Artifact Software
438-345-3369
rwheeler@artifact-software.com
Re: [DISCUSS] Management server default port conflict
Posted by Ron Wheeler <rw...@artifact-software.com.INVALID>.
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.angus@shapeblue.com
> www.shapeblue.com
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
> -----Original Message-----
> From: Wei ZHOU <us...@gmail.com>
> 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 <rw...@artifact-software.com.invalid> 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,
>>> <rw...@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 <ro...@shapeblue.com>
>>>>> Sent: 01 July 2020 13:04
>>>>> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>;
>>>> users@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 <Ab...@shapeblue.com>
>>>>> Sent: Wednesday, July 1, 2020 11:14
>>>>> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>;
>>>> users@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.w
>> ith(CloudStackExtendedLifeCycle.java:114)
>>>>> at
>> org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.wit
>> h(CloudStackExtendedLifeCycle.java:153)
>>>>> at
>> org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.con
>> figure(CloudStackExtendedLifeCycle.java:110)
>>>>> at
>> org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.sta
>> rt(CloudStackExtendedLifeCycle.java:55)
>>>>> at
>> org.springframework.context.support.DefaultLifecycleProcessor.doStart(
>> DefaultLifecycleProcessor.java:182)
>>>>> at
>> org.springframework.context.support.DefaultLifecycleProcessor.access$2
>> 00(DefaultLifecycleProcessor.java:53)
>>>>> at
>> org.springframework.context.support.DefaultLifecycleProcessor$Lifecycl
>> eGroup.start(DefaultLifecycleProcessor.java:360)
>>>>> at
>> org.springframework.context.support.DefaultLifecycleProcessor.startBea
>> ns(DefaultLifecycleProcessor.java:158)
>>>>> at
>> org.springframework.context.support.DefaultLifecycleProcessor.onRefres
>> h(DefaultLifecycleProcessor.java:122)
>>>>> at
>> org.springframework.context.support.AbstractApplicationContext.finishR
>> efresh(AbstractApplicationContext.java:894)
>>>>> at
>> org.springframework.context.support.AbstractApplicationContext.refresh
>> (AbstractApplicationContext.java:553)
>>>>> at
>> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
>> Set.loadContext(DefaultModuleDefinitionSet.java:144)
>>>>> at
>> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
>> Set$2.with(DefaultModuleDefinitionSet.java:121)
>>>>> at
>> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
>> Set.withModule(DefaultModuleDefinitionSet.java:244)
>>>>> at
>> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
>> Set.withModule(DefaultModuleDefinitionSet.java:249)
>>>>> at
>> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
>> Set.withModule(DefaultModuleDefinitionSet.java:249)
>>>>> at
>> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
>> Set.withModule(DefaultModuleDefinitionSet.java:232)
>>>>> at
>> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
>> Set.loadContexts(DefaultModuleDefinitionSet.java:116)
>>>>> at
>> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
>> Set.load(DefaultModuleDefinitionSet.java:78)
>>>>> at
>> org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory.
>> loadModules(ModuleBasedContextFactory.java:37)
>>>>> at
>> org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.in
>> it(CloudStackSpringContext.java:70)
>>>>> at
>> org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.<i
>> nit>(CloudStackSpringContext.java:57)
>>>>> at
>> org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.<i
>> nit>(CloudStackSpringContext.java:61)
>>>>> at
>> org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListene
>> r.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(ContextHa
>> ndler.java:889)
>>>>> at
>> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletCo
>> ntextHandler.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(ServletContext
>> Handler.java:275)
>>>>> at
>>>> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:5
>>>> 24)
>>>>> at
>> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeC
>> ycle.java:72)
>>>>> at
>> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLif
>> eCycle.java:169)
>>>>> at
>> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerL
>> ifeCycle.java:110)
>>>>> at
>> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandl
>> er.java:97)
>>>>> at
>> org.eclipse.jetty.server.handler.gzip.GzipHandler.doStart(GzipHandler.
>> java:425)
>>>>> at
>> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeC
>> ycle.java:72)
>>>>> at
>> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLif
>> eCycle.java:169)
>>>>> at
>> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerL
>> ifeCycle.java:117)
>>>>> at
>> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandl
>> er.java:97)
>>>>> at
>> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeC
>> ycle.java:72)
>>>>> at
>> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLif
>> eCycle.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.Kumar@shapeblue.com
>>>>> www.shapeblue.com<http://www.shapeblue.com>
>>>>> 3 London Bridge Street, 3rd floor, News Building, London SE1
>>>>> 9SGUK @shapeblue
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> rohit.yadav@shapeblue.com
>>>>> www.shapeblue.com<http://www.shapeblue.com>
>>>>> 3 London Bridge Street, 3rd floor, News Building, London SE1
>>>>> 9SGUK @shapeblue
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Abhishek.Kumar@shapeblue.com
>>>>> www.shapeblue.com
>>>>> 3 London Bridge Street, 3rd floor, News Building, London SE1
>>>>> 9SGUK @shapeblue
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Ron Wheeler
>>>> Artifact Software
>>>> 438-345-3369
>>>> rwheeler@artifact-software.com
>>>>
>>>>
>> --
>> Ron Wheeler
>> Artifact Software
>> 438-345-3369
>> rwheeler@artifact-software.com
>>
>>
--
Ron Wheeler
Artifact Software
438-345-3369
rwheeler@artifact-software.com
RE: [DISCUSS] Management server default port conflict
Posted by Paul Angus <pa...@shapeblue.com>.
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.angus@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
-----Original Message-----
From: Wei ZHOU <us...@gmail.com>
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 <rw...@artifact-software.com.invalid> 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,
> > <rw...@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 <ro...@shapeblue.com>
> >>> Sent: 01 July 2020 13:04
> >>> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>;
> >> users@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 <Ab...@shapeblue.com>
> >>> Sent: Wednesday, July 1, 2020 11:14
> >>> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>;
> >> users@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.w
> ith(CloudStackExtendedLifeCycle.java:114)
> >>> at
> >>
> org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.wit
> h(CloudStackExtendedLifeCycle.java:153)
> >>> at
> >>
> org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.con
> figure(CloudStackExtendedLifeCycle.java:110)
> >>> at
> >>
> org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.sta
> rt(CloudStackExtendedLifeCycle.java:55)
> >>> at
> >>
> org.springframework.context.support.DefaultLifecycleProcessor.doStart(
> DefaultLifecycleProcessor.java:182)
> >>> at
> >>
> org.springframework.context.support.DefaultLifecycleProcessor.access$2
> 00(DefaultLifecycleProcessor.java:53)
> >>> at
> >>
> org.springframework.context.support.DefaultLifecycleProcessor$Lifecycl
> eGroup.start(DefaultLifecycleProcessor.java:360)
> >>> at
> >>
> org.springframework.context.support.DefaultLifecycleProcessor.startBea
> ns(DefaultLifecycleProcessor.java:158)
> >>> at
> >>
> org.springframework.context.support.DefaultLifecycleProcessor.onRefres
> h(DefaultLifecycleProcessor.java:122)
> >>> at
> >>
> org.springframework.context.support.AbstractApplicationContext.finishR
> efresh(AbstractApplicationContext.java:894)
> >>> at
> >>
> org.springframework.context.support.AbstractApplicationContext.refresh
> (AbstractApplicationContext.java:553)
> >>> at
> >>
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
> Set.loadContext(DefaultModuleDefinitionSet.java:144)
> >>> at
> >>
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
> Set$2.with(DefaultModuleDefinitionSet.java:121)
> >>> at
> >>
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
> Set.withModule(DefaultModuleDefinitionSet.java:244)
> >>> at
> >>
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
> Set.withModule(DefaultModuleDefinitionSet.java:249)
> >>> at
> >>
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
> Set.withModule(DefaultModuleDefinitionSet.java:249)
> >>> at
> >>
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
> Set.withModule(DefaultModuleDefinitionSet.java:232)
> >>> at
> >>
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
> Set.loadContexts(DefaultModuleDefinitionSet.java:116)
> >>> at
> >>
> org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition
> Set.load(DefaultModuleDefinitionSet.java:78)
> >>> at
> >>
> org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory.
> loadModules(ModuleBasedContextFactory.java:37)
> >>> at
> >>
> org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.in
> it(CloudStackSpringContext.java:70)
> >>> at
> >>
> org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.<i
> nit>(CloudStackSpringContext.java:57)
> >>> at
> >>
> org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.<i
> nit>(CloudStackSpringContext.java:61)
> >>> at
> >>
> org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListene
> r.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(ContextHa
> ndler.java:889)
> >>> at
> >>
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletCo
> ntextHandler.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(ServletContext
> Handler.java:275)
> >>> at
> >> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:5
> >> 24)
> >>> at
> >>
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeC
> ycle.java:72)
> >>> at
> >>
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLif
> eCycle.java:169)
> >>> at
> >>
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerL
> ifeCycle.java:110)
> >>> at
> >>
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandl
> er.java:97)
> >>> at
> >>
> org.eclipse.jetty.server.handler.gzip.GzipHandler.doStart(GzipHandler.
> java:425)
> >>> at
> >>
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeC
> ycle.java:72)
> >>> at
> >>
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLif
> eCycle.java:169)
> >>> at
> >>
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerL
> ifeCycle.java:117)
> >>> at
> >>
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandl
> er.java:97)
> >>> at
> >>
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeC
> ycle.java:72)
> >>> at
> >>
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLif
> eCycle.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.Kumar@shapeblue.com
> >>> www.shapeblue.com<http://www.shapeblue.com>
> >>> 3 London Bridge Street, 3rd floor, News Building, London SE1
> >>> 9SGUK @shapeblue
> >>>
> >>>
> >>>
> >>>
> >>> rohit.yadav@shapeblue.com
> >>> www.shapeblue.com<http://www.shapeblue.com>
> >>> 3 London Bridge Street, 3rd floor, News Building, London SE1
> >>> 9SGUK @shapeblue
> >>>
> >>>
> >>>
> >>>
> >>> Abhishek.Kumar@shapeblue.com
> >>> www.shapeblue.com
> >>> 3 London Bridge Street, 3rd floor, News Building, London SE1
> >>> 9SGUK @shapeblue
> >>>
> >>>
> >>>
> >> --
> >> Ron Wheeler
> >> Artifact Software
> >> 438-345-3369
> >> rwheeler@artifact-software.com
> >>
> >>
>
> --
> Ron Wheeler
> Artifact Software
> 438-345-3369
> rwheeler@artifact-software.com
>
>
Re: [DISCUSS] Management server default port conflict
Posted by Ron Wheeler <rw...@artifact-software.com.INVALID>.
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
> <rw...@artifact-software.com.invalid> 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,
>>> <rw...@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 <ro...@shapeblue.com>
>>>>> Sent: 01 July 2020 13:04
>>>>> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>;
>>>> users@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 <Ab...@shapeblue.com>
>>>>> Sent: Wednesday, July 1, 2020 11:14
>>>>> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>;
>>>> users@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.Kumar@shapeblue.com
>>>>> www.shapeblue.com<http://www.shapeblue.com>
>>>>> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
>>>>> @shapeblue
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> rohit.yadav@shapeblue.com
>>>>> www.shapeblue.com<http://www.shapeblue.com>
>>>>> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
>>>>> @shapeblue
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Abhishek.Kumar@shapeblue.com
>>>>> www.shapeblue.com
>>>>> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
>>>>> @shapeblue
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Ron Wheeler
>>>> Artifact Software
>>>> 438-345-3369
>>>> rwheeler@artifact-software.com
>>>>
>>>>
>> --
>> Ron Wheeler
>> Artifact Software
>> 438-345-3369
>> rwheeler@artifact-software.com
>>
>>
--
Ron Wheeler
Artifact Software
438-345-3369
rwheeler@artifact-software.com
Re: [DISCUSS] Management server default port conflict
Posted by Wei ZHOU <us...@gmail.com>.
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
<rw...@artifact-software.com.invalid> 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,
> > <rw...@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 <ro...@shapeblue.com>
> >>> Sent: 01 July 2020 13:04
> >>> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>;
> >> users@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 <Ab...@shapeblue.com>
> >>> Sent: Wednesday, July 1, 2020 11:14
> >>> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>;
> >> users@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.Kumar@shapeblue.com
> >>> www.shapeblue.com<http://www.shapeblue.com>
> >>> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> >>> @shapeblue
> >>>
> >>>
> >>>
> >>>
> >>> rohit.yadav@shapeblue.com
> >>> www.shapeblue.com<http://www.shapeblue.com>
> >>> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> >>> @shapeblue
> >>>
> >>>
> >>>
> >>>
> >>> Abhishek.Kumar@shapeblue.com
> >>> www.shapeblue.com
> >>> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> >>> @shapeblue
> >>>
> >>>
> >>>
> >> --
> >> Ron Wheeler
> >> Artifact Software
> >> 438-345-3369
> >> rwheeler@artifact-software.com
> >>
> >>
>
> --
> Ron Wheeler
> Artifact Software
> 438-345-3369
> rwheeler@artifact-software.com
>
>
Re: [DISCUSS] Management server default port conflict
Posted by Ron Wheeler <rw...@artifact-software.com.INVALID>.
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,
> <rw...@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 <ro...@shapeblue.com>
>>> Sent: 01 July 2020 13:04
>>> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>;
>> users@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 <Ab...@shapeblue.com>
>>> Sent: Wednesday, July 1, 2020 11:14
>>> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>;
>> users@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.Kumar@shapeblue.com
>>> www.shapeblue.com<http://www.shapeblue.com>
>>> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
>>> @shapeblue
>>>
>>>
>>>
>>>
>>> rohit.yadav@shapeblue.com
>>> www.shapeblue.com<http://www.shapeblue.com>
>>> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
>>> @shapeblue
>>>
>>>
>>>
>>>
>>> Abhishek.Kumar@shapeblue.com
>>> www.shapeblue.com
>>> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
>>> @shapeblue
>>>
>>>
>>>
>> --
>> Ron Wheeler
>> Artifact Software
>> 438-345-3369
>> rwheeler@artifact-software.com
>>
>>
--
Ron Wheeler
Artifact Software
438-345-3369
rwheeler@artifact-software.com
Re: [DISCUSS] Management server default port conflict
Posted by Andrija Panic <an...@gmail.com>.
(true that, Ron...)
On Wed, 1 Jul 2020, 15:27 Ron Wheeler,
<rw...@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 <ro...@shapeblue.com>
> > Sent: 01 July 2020 13:04
> > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>;
> users@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 <Ab...@shapeblue.com>
> > Sent: Wednesday, July 1, 2020 11:14
> > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>;
> users@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.Kumar@shapeblue.com
> > www.shapeblue.com<http://www.shapeblue.com>
> > 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> > @shapeblue
> >
> >
> >
> >
> > rohit.yadav@shapeblue.com
> > www.shapeblue.com<http://www.shapeblue.com>
> > 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> > @shapeblue
> >
> >
> >
> >
> > Abhishek.Kumar@shapeblue.com
> > www.shapeblue.com
> > 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> > @shapeblue
> >
> >
> >
>
> --
> Ron Wheeler
> Artifact Software
> 438-345-3369
> rwheeler@artifact-software.com
>
>
Re: [DISCUSS] Management server default port conflict
Posted by Ron Wheeler <rw...@artifact-software.com.INVALID>.
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 <ro...@shapeblue.com>
> Sent: 01 July 2020 13:04
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>; users@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 <Ab...@shapeblue.com>
> Sent: Wednesday, July 1, 2020 11:14
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>; users@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.Kumar@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
> rohit.yadav@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
> Abhishek.Kumar@shapeblue.com
> www.shapeblue.com
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
--
Ron Wheeler
Artifact Software
438-345-3369
rwheeler@artifact-software.com
Re: [DISCUSS] Management server default port conflict
Posted by Abhishek Kumar <Ab...@shapeblue.com>.
+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 <ro...@shapeblue.com>
Sent: 01 July 2020 13:04
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>; users@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 <Ab...@shapeblue.com>
Sent: Wednesday, July 1, 2020 11:14
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>; users@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.Kumar@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
rohit.yadav@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
Abhishek.Kumar@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
Re: [DISCUSS] Management server default port conflict
Posted by Andrija Panic <an...@gmail.com>.
Besides updating the documentation, I'm tempted to even explicitly add a
command that would disable the cockpit service on boot and stop it (and
echo the message that we've disabled it...)- as part of the
cloudstack-setup-management or similar.
Otherwise, novice users will certainly stumble sooner or later on this
issue.
On Wed, 1 Jul 2020 at 09:34, Rohit Yadav <ro...@shapeblue.com> wrote:
> 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 <Ab...@shapeblue.com>
> Sent: Wednesday, July 1, 2020 11:14
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>;
> users@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.Kumar@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
> rohit.yadav@shapeblue.com
> www.shapeblue.com
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
--
Andrija Panić
Re: [DISCUSS] Management server default port conflict
Posted by nu...@li.nux.ro.
+1, agree with Rohit
On 2020-07-01 08:34, Rohit Yadav wrote:
> 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 <Ab...@shapeblue.com>
> Sent: Wednesday, July 1, 2020 11:14
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>;
> users@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.Kumar@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
> rohit.yadav@shapeblue.com
> www.shapeblue.com
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
Re: [DISCUSS] Management server default port conflict
Posted by nu...@li.nux.ro.
+1, agree with Rohit
On 2020-07-01 08:34, Rohit Yadav wrote:
> 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 <Ab...@shapeblue.com>
> Sent: Wednesday, July 1, 2020 11:14
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>;
> users@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.Kumar@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
> rohit.yadav@shapeblue.com
> www.shapeblue.com
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
Re: [DISCUSS] Management server default port conflict
Posted by Abhishek Kumar <Ab...@shapeblue.com>.
+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 <ro...@shapeblue.com>
Sent: 01 July 2020 13:04
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>; users@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 <Ab...@shapeblue.com>
Sent: Wednesday, July 1, 2020 11:14
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>; users@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.Kumar@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
rohit.yadav@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
Abhishek.Kumar@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
Re: [DISCUSS] Management server default port conflict
Posted by Rohit Yadav <ro...@shapeblue.com>.
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 <Ab...@shapeblue.com>
Sent: Wednesday, July 1, 2020 11:14
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>; users@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.Kumar@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
rohit.yadav@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
Re: [DISCUSS] Management server default port conflict
Posted by Rohit Yadav <ro...@shapeblue.com>.
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 <Ab...@shapeblue.com>
Sent: Wednesday, July 1, 2020 11:14
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>; users@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.Kumar@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
rohit.yadav@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue