You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Rafael Fonseca <rs...@gmail.com> on 2015/05/12 10:59:13 UTC
Cloudstack Repackaging / Distro support
Hi all,
I'm reworking the packaging system in cloudstack, and would like to gather
your opinion on the following:
- Fedora 2x runs systemd's cockpit on port 9090 by default
This is a deal breaker for the cluster servlet port on this OS, the two
possibilities would be to either pack changes to fedora's config on rpm
install or simply change the servlet port to another one that does not
clash on any distro.. any comments/suggestions?
- Tomcat is not listening on port 80
Tomcat is using port 8080, which makes the user have to specify that in
the browser.. should we change it? In ubuntu it's already running under
jsvc, so it shouldn't be a problem.. same can be arranged for centos/other
distros.
- No link on the tomcat root (http://management-server/ can link internally
to http://management-server/client , this makes it easier for new users who
don't know the URL for the UI :)
Thanks for your input :)
Re: Cloudstack Repackaging / Distro support
Posted by Nux! <nu...@li.nux.ro>.
Hi,
A bit late to this party. My 3 pence:
+1 for making things more configurable (e.g. IP/port binding)
-1 for auto-configuring any sort of proxies or making any sort of assumptions on behalf of the sysadmin - this is the stuff that pisses off sysadmins actually
-1 for changing default ports
/imho
Lucian
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
----- Original Message -----
> From: "Rafael Fonseca" <rs...@gmail.com>
> To: dev@cloudstack.apache.org
> Sent: Tuesday, 12 May, 2015 09:59:13
> Subject: Cloudstack Repackaging / Distro support
> Hi all,
>
> I'm reworking the packaging system in cloudstack, and would like to gather
> your opinion on the following:
>
> - Fedora 2x runs systemd's cockpit on port 9090 by default
> This is a deal breaker for the cluster servlet port on this OS, the two
> possibilities would be to either pack changes to fedora's config on rpm
> install or simply change the servlet port to another one that does not
> clash on any distro.. any comments/suggestions?
>
> - Tomcat is not listening on port 80
> Tomcat is using port 8080, which makes the user have to specify that in
> the browser.. should we change it? In ubuntu it's already running under
> jsvc, so it shouldn't be a problem.. same can be arranged for centos/other
> distros.
>
> - No link on the tomcat root (http://management-server/ can link internally
> to http://management-server/client , this makes it easier for new users who
> don't know the URL for the UI :)
>
> Thanks for your input :)
Re: Cloudstack Repackaging / Distro support
Posted by Erik Weber <te...@gmail.com>.
On Tue, May 12, 2015 at 11:51 AM, Rafael Fonseca <rs...@gmail.com>
wrote:
> I guess the rationale behind putting it on 8080 is because this is the
> default for tomcat :)
> Also, by default, unprivileged accounts (non-root) are unable to listen on
> ports under 1024 like 80/443 (which is the reason of tomcat shipping it by
> default on 8080) this is easily fixable by daemonizing it (with jsvc for
> example, like it's already done for debian packaging).
> Another simple workaround i usually use for this, is to have iptables
> redirect port 80 to 8080 seamlessly, this allows the service to be
> available both on port 80 and 8080 ;)
>
>
Wido has a point though, who's putting tomcat directly on the line? Atleast
in my experience we only do that for testing / lab, and IMHO we should
package for production.
--
Erik
Re: Cloudstack Repackaging / Distro support
Posted by Rafael Fonseca <rs...@gmail.com>.
I guess the rationale behind putting it on 8080 is because this is the
default for tomcat :)
Also, by default, unprivileged accounts (non-root) are unable to listen on
ports under 1024 like 80/443 (which is the reason of tomcat shipping it by
default on 8080) this is easily fixable by daemonizing it (with jsvc for
example, like it's already done for debian packaging).
Another simple workaround i usually use for this, is to have iptables
redirect port 80 to 8080 seamlessly, this allows the service to be
available both on port 80 and 8080 ;)
On Tue, May 12, 2015 at 11:37 AM, Erik Weber <te...@gmail.com> wrote:
> On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca <rs...@gmail.com>
> wrote:
>
> > Hi all,
> >
> > I'm reworking the packaging system in cloudstack, and would like to
> gather
> > your opinion on the following:
> >
> > - Fedora 2x runs systemd's cockpit on port 9090 by default
> > This is a deal breaker for the cluster servlet port on this OS, the two
> > possibilities would be to either pack changes to fedora's config on rpm
> > install or simply change the servlet port to another one that does not
> > clash on any distro.. any comments/suggestions?
> >
> > - Tomcat is not listening on port 80
> > Tomcat is using port 8080, which makes the user have to specify that
> in
> > the browser.. should we change it? In ubuntu it's already running under
> > jsvc, so it shouldn't be a problem.. same can be arranged for
> centos/other
> > distros.
> >
>
> Is it possible to ask the user for this during installation and default to
> either 80 or 8080? I know Debian has a way to interact with the user during
> install, not sure about RedHat.
>
> I don't know the rationale behind putting it on port 8080 in the first
> place, but personally I don't see a problem moving it to port 80.
>
>
> > - No link on the tomcat root (http://management-server/ can link
> > internally
> > to http://management-server/client , this makes it easier for new users
> > who
> > don't know the URL for the UI :)
> >
> >
> Sounds like a good idea to me, I always forget to add /client when I browse
> to new installations.
>
> --
> Erik
>
Re: Cloudstack Repackaging / Distro support
Posted by Rafael Fonseca <rs...@gmail.com>.
Hi Paul,
I'd like to have time to do what you proposed, but unfortunately after
tomorrow i'll be away for almost a week (maybe then, if my changes haven't
been merged yet)
These are just some small details, the bigger changes are noted here:
https://github.com/apache/cloudstack/pull/238
Have a look and help testing plz :)
Any other distros you guys would like to support? I'm changing port 9090 to
something else (if no one is opposed) and committing support for fedora2x
tonight (also compilation and tests successfull with java8-devel) :)
On Tue, May 12, 2015 at 3:28 PM, Paul Angus <pa...@shapeblue.com>
wrote:
> Hi Rafael,
>
> I like your ideal. Perhaps you could create a wiki-page and Jira Issue so
> that everyone can see your specific proposed changes. And comment.
>
> Regards,
>
> Paul Angus
> Cloud Architect
> D: +44 20 3468 5163 |S: +44 20 3603 0540 | M: +44 7711 418 784 | T:
> @CloudyAngus
> paul.angus@shapeblue.com
>
> -----Original Message-----
> From: Erik Weber [mailto:terbolous@gmail.com]
> Sent: 12 May 2015 14:17
> To: dev
> Subject: Re: Cloudstack Repackaging / Distro support
>
> It's easier to maintain a playbook/cookbook/manifest than a site-config
> (that rarely should change)? :-)
>
> --
> Erik
>
> On Tue, May 12, 2015 at 3:14 PM, Jeff Moody <je...@fifthecho.com> wrote:
>
> > Also a good idea, but would be yet another package to be
> > maintained...albeit a small one.
> > Might be easier to release a pair of Ansible playbooks/Chef
> > cookbooks/Puppet manifests/etc.
> >
> > On Tue, 2015-05-12 at 15:11 +0200, Erik Weber wrote:
> > > How about bundling the httpd/nginx configuration in a separate
> > > optional package?
> > > I have no idea for a name, but it could depend on either httpd and
> > > nginx, and include a site config that works out of the box.
> > >
> > > Should work great for those who need an easy setup, and still allow
> > > those who set up external loadbalancers to do as before.
> > >
> >
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Software Engineering<
> http://shapeblue.com/cloudstack-software-engineering/>
> CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<
> http://shapeblue.com/cloudstack-training/>
>
> This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Shape Blue Ltd or related companies. If you are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error. Shape Blue Ltd is a
> company incorporated in England & Wales. ShapeBlue Services India LLP is a
> company incorporated in India and is operated under license from Shape Blue
> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil
> and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is
> a company registered by The Republic of South Africa and is traded under
> license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>
RE: Cloudstack Repackaging / Distro support
Posted by Paul Angus <pa...@shapeblue.com>.
Hi Rafael,
I like your ideal. Perhaps you could create a wiki-page and Jira Issue so that everyone can see your specific proposed changes. And comment.
Regards,
Paul Angus
Cloud Architect
D: +44 20 3468 5163 |S: +44 20 3603 0540 | M: +44 7711 418 784 | T: @CloudyAngus
paul.angus@shapeblue.com
-----Original Message-----
From: Erik Weber [mailto:terbolous@gmail.com]
Sent: 12 May 2015 14:17
To: dev
Subject: Re: Cloudstack Repackaging / Distro support
It's easier to maintain a playbook/cookbook/manifest than a site-config (that rarely should change)? :-)
--
Erik
On Tue, May 12, 2015 at 3:14 PM, Jeff Moody <je...@fifthecho.com> wrote:
> Also a good idea, but would be yet another package to be
> maintained...albeit a small one.
> Might be easier to release a pair of Ansible playbooks/Chef
> cookbooks/Puppet manifests/etc.
>
> On Tue, 2015-05-12 at 15:11 +0200, Erik Weber wrote:
> > How about bundling the httpd/nginx configuration in a separate
> > optional package?
> > I have no idea for a name, but it could depend on either httpd and
> > nginx, and include a site config that works out of the box.
> >
> > Should work great for those who need an easy setup, and still allow
> > those who set up external loadbalancers to do as before.
> >
>
Find out more about ShapeBlue and our range of CloudStack related services
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: Cloudstack Repackaging / Distro support
Posted by Rafael Fonseca <rs...@gmail.com>.
That is easy enough to check at install time :)
If we want to avoid that scenario the following could be done:
- Check if anything is using port 80 at config time, warn and don't config
anything if it is
- Load/Unload the redirect rule on tomcat startup, this will make port 80
available to other processes when tomcat is stopped
- Listen on port 80 with an empty connector to grab hold of the port
(throwing a warning to the user launching httpd as a separate process that
the port is in use)
On Tue, May 12, 2015 at 3:34 PM, Erik Weber <te...@gmail.com> wrote:
> On Tue, May 12, 2015 at 3:30 PM, Rafael Fonseca <rs...@gmail.com>
> wrote:
>
> > Keeping a couple of config files for httpd/nginx should be quite easy, we
> > could configure it optionally (with a prompt) when running the
> > cloud-setup-management script, for instance.
> > We can optionally also just configure a redirect rule for port 80 on the
> > same prompt if user doesn't want proxying, that way it will be reachable
> > both on port 80 AND 8080 :)
> >
> >
>
> That could easily lead to confusion if the user is running something else,
> like httpd, on port 80.
>
> Although I like the efforts made to make things easier, assumptions is a
> bad thing.
>
> --
> Erik
>
Re: Cloudstack Repackaging / Distro support
Posted by Erik Weber <te...@gmail.com>.
On Tue, May 12, 2015 at 3:30 PM, Rafael Fonseca <rs...@gmail.com>
wrote:
> Keeping a couple of config files for httpd/nginx should be quite easy, we
> could configure it optionally (with a prompt) when running the
> cloud-setup-management script, for instance.
> We can optionally also just configure a redirect rule for port 80 on the
> same prompt if user doesn't want proxying, that way it will be reachable
> both on port 80 AND 8080 :)
>
>
That could easily lead to confusion if the user is running something else,
like httpd, on port 80.
Although I like the efforts made to make things easier, assumptions is a
bad thing.
--
Erik
Re: Cloudstack Repackaging / Distro support
Posted by Rafael Fonseca <rs...@gmail.com>.
Keeping a couple of config files for httpd/nginx should be quite easy, we
could configure it optionally (with a prompt) when running the
cloud-setup-management script, for instance.
We can optionally also just configure a redirect rule for port 80 on the
same prompt if user doesn't want proxying, that way it will be reachable
both on port 80 AND 8080 :)
How about changing the 9090 port for server? any thoughts there? should be
quick enough to scour through the code to find any references.. that would
fix supportability for Fedora 2x and the only drawback i see is that some
might need to create new firewall rules after upgrading to this :)
On Tue, May 12, 2015 at 3:17 PM, Erik Weber <te...@gmail.com> wrote:
> It's easier to maintain a playbook/cookbook/manifest than a site-config
> (that rarely should change)? :-)
>
> --
> Erik
>
> On Tue, May 12, 2015 at 3:14 PM, Jeff Moody <je...@fifthecho.com> wrote:
>
> > Also a good idea, but would be yet another package to be
> > maintained...albeit a small one.
> > Might be easier to release a pair of Ansible playbooks/Chef
> > cookbooks/Puppet manifests/etc.
> >
> > On Tue, 2015-05-12 at 15:11 +0200, Erik Weber wrote:
> > > How about bundling the httpd/nginx configuration in a separate
> > > optional
> > > package?
> > > I have no idea for a name, but it could depend on either httpd and
> > > nginx,
> > > and include a site config that works out of the box.
> > >
> > > Should work great for those who need an easy setup, and still allow
> > > those
> > > who set up external loadbalancers to do as before.
> > >
> >
>
Re: Cloudstack Repackaging / Distro support
Posted by Erik Weber <te...@gmail.com>.
It's easier to maintain a playbook/cookbook/manifest than a site-config
(that rarely should change)? :-)
--
Erik
On Tue, May 12, 2015 at 3:14 PM, Jeff Moody <je...@fifthecho.com> wrote:
> Also a good idea, but would be yet another package to be
> maintained...albeit a small one.
> Might be easier to release a pair of Ansible playbooks/Chef
> cookbooks/Puppet manifests/etc.
>
> On Tue, 2015-05-12 at 15:11 +0200, Erik Weber wrote:
> > How about bundling the httpd/nginx configuration in a separate
> > optional
> > package?
> > I have no idea for a name, but it could depend on either httpd and
> > nginx,
> > and include a site config that works out of the box.
> >
> > Should work great for those who need an easy setup, and still allow
> > those
> > who set up external loadbalancers to do as before.
> >
>
Re: Cloudstack Repackaging / Distro support
Posted by Jeff Moody <je...@fifthecho.com>.
Also a good idea, but would be yet another package to be maintained...albeit a small one.
Might be easier to release a pair of Ansible playbooks/Chef cookbooks/Puppet manifests/etc.
On Tue, 2015-05-12 at 15:11 +0200, Erik Weber wrote:
> How about bundling the httpd/nginx configuration in a separate
> optional
> package?
> I have no idea for a name, but it could depend on either httpd and
> nginx,
> and include a site config that works out of the box.
>
> Should work great for those who need an easy setup, and still allow
> those
> who set up external loadbalancers to do as before.
>
Re: Cloudstack Repackaging / Distro support
Posted by Erik Weber <te...@gmail.com>.
How about bundling the httpd/nginx configuration in a separate optional
package?
I have no idea for a name, but it could depend on either httpd and nginx,
and include a site config that works out of the box.
Should work great for those who need an easy setup, and still allow those
who set up external loadbalancers to do as before.
--
Erik
On Tue, May 12, 2015 at 3:08 PM, Jeff Moody <je...@fifthecho.com> wrote:
> I'd say a safe middle-ground might be providing a working proxy config
> for Apache and for nginx in the docs or share directories and then
> pointing to those in the documentation as references to get the API
> proxied on 80/443.
>
> I do agree with leaving the default on 8080 as that's the default for
> Tomcat and a LOT of CloudStack drivers for different tools default to
> that port.
>
> On Tue, 2015-05-12 at 14:47 +0200, Rafael Fonseca wrote:
> > I'll stay away from touching port 80 for now, but isn't saving work
> > to the
> > admin one of cloudstack's main goals?
> >
> > That is also the main reason to package this stuff and have rules for
> > configuration :)
> >
> > I do see a lot of people complaining that cloudstack is hard to
> > setup and
> > has very long setup guides and a lot of stuff doesn't work on certain
> > environments... i aim to put an end to that.. hopefully even the
> > dumbest
> > sysadmin will be able to get it up and running without much effort
> > by the
> > time i'm done :) . The effort reduction is also always valid for
> > experienced sysadmins and developers ;)
> >
> >
> >
> >
> > On Tue, May 12, 2015 at 1:16 PM, Wido den Hollander <wi...@widodh.nl>
> > wrote:
> >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > >
> > >
> > > On 05/12/2015 12:03 PM, Rafael Fonseca wrote:
> > > > Wido,
> > > >
> > > > If we were to recommend proxying with httpd, shouldn't cloudstack
> > > > provide that as well out of the box?
> > >
> > > I'd stay away from that. Providing that out of the box means doing
> > > more stuff which an admin should do.
> > >
> > > Wido
> > >
> > > > Btw, there isn't really a big performance gain by proxying
> > > > through
> > > > httpd nowadays, the new version of the packaging also includes
> > > > using tomcat8, which has an improved http/nio connector, have a
> > > > look here for some performance benchmarks :) ->
> > > > http://www.tomcatexpert.com/blog/2010/03/24/myth-or-truth-one
> > > > -should-a
> > > lways-use-apache-httpd-front-apache-tomcat-improve-perform
> > > >
> > > > What i think is that if we are going to suggest configuring
> > > > httpd
> > > > on the same box we should do it automatically, if not, tomcat can
> > > > still run on port 80 by default and user can reverse proxy from
> > > > any
> > > > other machine :)
> > > >
> > > > Also, if we're sticking to tomcat, we should have scripts build
> > > > the APR/native connector for improved performance :)
> > > > http://tomcat.apache.org/native-doc/
> > > >
> > > > This would be an improvement independent from using or not
> > > > httpd/nginx in front of tomcat.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, May 12, 2015 at 11:45 AM, Wido den Hollander
> > > > <wi...@widodh.nl> wrote:
> > > >
> > > >
> > > >
> > > > On 05/12/2015 11:37 AM, Erik Weber wrote:
> > > > > > > On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca
> > > > > > > <rs...@gmail.com> wrote:
> > > > > > >
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > I'm reworking the packaging system in cloudstack, and
> > > > > > > > would
> > > > > > > > like to gather your opinion on the following:
> > > > > > > >
> > > > > > > > - Fedora 2x runs systemd's cockpit on port 9090 by
> > > > > > > > default
> > > > > > > > This is a deal breaker for the cluster servlet port on
> > > > > > > > this
> > > > > > > > OS, the two possibilities would be to either pack changes
> > > > > > > > to fedora's config on rpm install or simply change the
> > > > > > > > servlet port to another one that does not clash on any
> > > > > > > > distro.. any comments/suggestions?
> > > > > > > >
> > > > > > > > - Tomcat is not listening on port 80 Tomcat is using port
> > > > > > > > 8080, which makes the user have to specify that in the
> > > > > > > > browser.. should we change it? In ubuntu it's already
> > > > > > > > running under jsvc, so it shouldn't be a problem.. same
> > > > > > > > can
> > > > > > > > be arranged for centos/other distros.
> > > > > > > >
> > > > > > >
> > > > > > > Is it possible to ask the user for this during installation
> > > > > > > and default to either 80 or 8080? I know Debian has a way
> > > > > > > to
> > > > > > > interact with the user during install, not sure about
> > > > > > > RedHat.
> > > > > > >
> > > > > > > I don't know the rationale behind putting it on port 8080
> > > > > > > in
> > > > > > > the first place, but personally I don't see a problem
> > > > > > > moving
> > > > > > > it to port 80.
> > > > > > >
> > > >
> > > > I'd say to stick to 8080 and recommend anybody to use Apache /
> > > > Nginx to proxy towards Tomcat.
> > > >
> > > > > > >
> > > > > > > > - No link on the tomcat root (http://management-server/
> > > > > > > > can
> > > > > > > > link internally to http://management-server/client , this
> > > > > > > > makes it easier for new users who don't know the URL for
> > > > > > > > the UI :)
> > > > > > > >
> > > > > > > >
> > > > > > > Sounds like a good idea to me, I always forget to add
> > > > > > > /client
> > > > > > > when I browse to new installations.
> > > > > > >
> > > > >
> > > >
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1
> > >
> > > iQIcBAEBAgAGBQJVUeEFAAoJEAGbWC3bPspCupwQAJjU6Akq18N9QcPYiOK60NR5
> > > P9+MF0UFvu1N5nHJxYwEHjIqwuzN9957xqx6LK0nhyDMN8ECadvZXweT5XhXbh+5
> > > G7D1Wqilav7GqGiye+4zV2CLRUI8KBPrUMFHwk4C4o1SqE6YxiX7E8/WY+cx2nt2
> > > LRAwPIvc3IL5QRIbiDfFm19mJRExBvHIZCYsMAPMgag2p85HOzuGxQ/NCcME7nna
> > > ODlHkjrPaWF66vZtyMA289R1e0Bab7hbElirCsA0VoTP3gbrwNriDf1KSfmOzIJD
> > > VyaSq2kcDIrWYWjuXxtjhIKdxCCkopgqRvjjiEDCQ3LVDaMsh4PSjhl2SuSU24l4
> > > mX6DZXjnt+3U01FOj9Bc76K28hawB3+7qqYPEsWlboi7Jz5hn0j04Kn9wRa+ZbfF
> > > 8t1DUpdPDtWd+HsyV/fdKXKY1X4Q/P3SatrqVZBymnyT/l/ENvqYLzLcNXHN9NSl
> > > 8o0+vhmTJRdbK9QoNeB8QtmtU+VB4iyC6x5tfwgqLvRNsSep3mpEgrKVa3h1Ssaz
> > > 14ChxYSNktOLJM3JuKBHqzSM0lxOHOT7wkiSXiXlCpbaoVRLcge7U4PjJW/GCSrE
> > > a/BAUYQzSKBAS/OpZHFizmQ0J7ASXaFDlBwy5XBfV+4nZjtClVR4oN9VHAJJ8d2X
> > > Fl89s3wdH0L/ag6Sd/oj
> > > =nbJY
> > > -----END PGP SIGNATURE-----
> > >
>
Re: Cloudstack Repackaging / Distro support
Posted by Jeff Moody <je...@fifthecho.com>.
I'd say a safe middle-ground might be providing a working proxy config
for Apache and for nginx in the docs or share directories and then
pointing to those in the documentation as references to get the API
proxied on 80/443.
I do agree with leaving the default on 8080 as that's the default for
Tomcat and a LOT of CloudStack drivers for different tools default to
that port.
On Tue, 2015-05-12 at 14:47 +0200, Rafael Fonseca wrote:
> I'll stay away from touching port 80 for now, but isn't saving work
> to the
> admin one of cloudstack's main goals?
>
> That is also the main reason to package this stuff and have rules for
> configuration :)
>
> I do see a lot of people complaining that cloudstack is hard to
> setup and
> has very long setup guides and a lot of stuff doesn't work on certain
> environments... i aim to put an end to that.. hopefully even the
> dumbest
> sysadmin will be able to get it up and running without much effort
> by the
> time i'm done :) . The effort reduction is also always valid for
> experienced sysadmins and developers ;)
>
>
>
>
> On Tue, May 12, 2015 at 1:16 PM, Wido den Hollander <wi...@widodh.nl>
> wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> >
> > On 05/12/2015 12:03 PM, Rafael Fonseca wrote:
> > > Wido,
> > >
> > > If we were to recommend proxying with httpd, shouldn't cloudstack
> > > provide that as well out of the box?
> >
> > I'd stay away from that. Providing that out of the box means doing
> > more stuff which an admin should do.
> >
> > Wido
> >
> > > Btw, there isn't really a big performance gain by proxying
> > > through
> > > httpd nowadays, the new version of the packaging also includes
> > > using tomcat8, which has an improved http/nio connector, have a
> > > look here for some performance benchmarks :) ->
> > > http://www.tomcatexpert.com/blog/2010/03/24/myth-or-truth-one
> > > -should-a
> > lways-use-apache-httpd-front-apache-tomcat-improve-perform
> > >
> > > What i think is that if we are going to suggest configuring
> > > httpd
> > > on the same box we should do it automatically, if not, tomcat can
> > > still run on port 80 by default and user can reverse proxy from
> > > any
> > > other machine :)
> > >
> > > Also, if we're sticking to tomcat, we should have scripts build
> > > the APR/native connector for improved performance :)
> > > http://tomcat.apache.org/native-doc/
> > >
> > > This would be an improvement independent from using or not
> > > httpd/nginx in front of tomcat.
> > >
> > >
> > >
> > >
> > >
> > > On Tue, May 12, 2015 at 11:45 AM, Wido den Hollander
> > > <wi...@widodh.nl> wrote:
> > >
> > >
> > >
> > > On 05/12/2015 11:37 AM, Erik Weber wrote:
> > > > > > On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca
> > > > > > <rs...@gmail.com> wrote:
> > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > I'm reworking the packaging system in cloudstack, and
> > > > > > > would
> > > > > > > like to gather your opinion on the following:
> > > > > > >
> > > > > > > - Fedora 2x runs systemd's cockpit on port 9090 by
> > > > > > > default
> > > > > > > This is a deal breaker for the cluster servlet port on
> > > > > > > this
> > > > > > > OS, the two possibilities would be to either pack changes
> > > > > > > to fedora's config on rpm install or simply change the
> > > > > > > servlet port to another one that does not clash on any
> > > > > > > distro.. any comments/suggestions?
> > > > > > >
> > > > > > > - Tomcat is not listening on port 80 Tomcat is using port
> > > > > > > 8080, which makes the user have to specify that in the
> > > > > > > browser.. should we change it? In ubuntu it's already
> > > > > > > running under jsvc, so it shouldn't be a problem.. same
> > > > > > > can
> > > > > > > be arranged for centos/other distros.
> > > > > > >
> > > > > >
> > > > > > Is it possible to ask the user for this during installation
> > > > > > and default to either 80 or 8080? I know Debian has a way
> > > > > > to
> > > > > > interact with the user during install, not sure about
> > > > > > RedHat.
> > > > > >
> > > > > > I don't know the rationale behind putting it on port 8080
> > > > > > in
> > > > > > the first place, but personally I don't see a problem
> > > > > > moving
> > > > > > it to port 80.
> > > > > >
> > >
> > > I'd say to stick to 8080 and recommend anybody to use Apache /
> > > Nginx to proxy towards Tomcat.
> > >
> > > > > >
> > > > > > > - No link on the tomcat root (http://management-server/
> > > > > > > can
> > > > > > > link internally to http://management-server/client , this
> > > > > > > makes it easier for new users who don't know the URL for
> > > > > > > the UI :)
> > > > > > >
> > > > > > >
> > > > > > Sounds like a good idea to me, I always forget to add
> > > > > > /client
> > > > > > when I browse to new installations.
> > > > > >
> > > >
> > >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1
> >
> > iQIcBAEBAgAGBQJVUeEFAAoJEAGbWC3bPspCupwQAJjU6Akq18N9QcPYiOK60NR5
> > P9+MF0UFvu1N5nHJxYwEHjIqwuzN9957xqx6LK0nhyDMN8ECadvZXweT5XhXbh+5
> > G7D1Wqilav7GqGiye+4zV2CLRUI8KBPrUMFHwk4C4o1SqE6YxiX7E8/WY+cx2nt2
> > LRAwPIvc3IL5QRIbiDfFm19mJRExBvHIZCYsMAPMgag2p85HOzuGxQ/NCcME7nna
> > ODlHkjrPaWF66vZtyMA289R1e0Bab7hbElirCsA0VoTP3gbrwNriDf1KSfmOzIJD
> > VyaSq2kcDIrWYWjuXxtjhIKdxCCkopgqRvjjiEDCQ3LVDaMsh4PSjhl2SuSU24l4
> > mX6DZXjnt+3U01FOj9Bc76K28hawB3+7qqYPEsWlboi7Jz5hn0j04Kn9wRa+ZbfF
> > 8t1DUpdPDtWd+HsyV/fdKXKY1X4Q/P3SatrqVZBymnyT/l/ENvqYLzLcNXHN9NSl
> > 8o0+vhmTJRdbK9QoNeB8QtmtU+VB4iyC6x5tfwgqLvRNsSep3mpEgrKVa3h1Ssaz
> > 14ChxYSNktOLJM3JuKBHqzSM0lxOHOT7wkiSXiXlCpbaoVRLcge7U4PjJW/GCSrE
> > a/BAUYQzSKBAS/OpZHFizmQ0J7ASXaFDlBwy5XBfV+4nZjtClVR4oN9VHAJJ8d2X
> > Fl89s3wdH0L/ag6Sd/oj
> > =nbJY
> > -----END PGP SIGNATURE-----
> >
Re: Cloudstack Repackaging / Distro support
Posted by Erik Weber <te...@gmail.com>.
On Tue, May 12, 2015 at 5:26 PM, Rafael Fonseca <rs...@gmail.com>
wrote:
> That is a good point David, but ideally, if we are recommending the use of
> a reverse proxy because our out of the box solution isn't good enough for
> production, i'd propose either:
>
>
It's not really about 'not good enough', but most shops have their own way
of doing things.
We use Netscaler to load balance cloudstack, others use F5, others use
HAProxy, some use nginx and a bunch is probably using httpd.
I'm not saying that it's a bad idea to provide some default configs, but I
don't think any production clouds are going to use it, basically because
everyone has their own way of doing things.
Preferably in a separate package, otherwise you have to require httpd (or
whatever) to be installed, which easily becomes a PITA if you don't use
httpd.
--
Erik
Re: Cloudstack Repackaging / Distro support
Posted by David Nalley <da...@gnsa.us>.
We should allow configurability, but, in the future, we should also
register the port. - you'll note Bacula, for instance, doesn't have
any clashes.
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=111
On Tue, May 12, 2015 at 5:15 PM, Carlos Reátegui <cr...@gmail.com> wrote:
> How about having the installer check if 9090 is in use and ask for an alternative port if so.
>
> I guess this would mean you first have to make the port configurable. During upgrades the check would not be made and leave the config as is.
>
>
>> On May 12, 2015, at 2:09 PM, Rafael Fonseca <rs...@gmail.com> wrote:
>>
>> Marcus, it has not made it to CentOS/RedHat Server yet, but it's on Fedora
>> Server, not desktop.. on by default.
>>
>> I can give a hand with those python scripts next week hopefully :)
>>
>> On Tue, May 12, 2015 at 9:04 PM, Marcus <shadowsor@gmail.com <ma...@gmail.com>> wrote:
>>
>>> I understand, but it's the sort of thing most admins will disable or remove
>>> in their kickstart as a liability. RedHat has had default system management
>>> services like this before and they were not well received (I forget the
>>> name of the remote system management utility that shipped with RHEL4/5). If
>>> it does make it from the desktop to the server as a default service though,
>>> then I agree we will have to address it as a part of our CentOS management
>>> server support.
>>>
>>> Don't get me started on the python config scripts, they've been a pain,
>>> honestly. Particularly on the hypervisor side, it opens a bunch of ports
>>> that not everyone needs, edits libvirt configs, and conflicts with
>>> configuration management. They're great in the interest of someone spinning
>>> up a quick proof of concept or small environment, but larger environments
>>> usually manage their own configs and the python scripts touch all sorts of
>>> things and require a post-agent reconfigure. If we make the ports
>>> configurable, the script should probably just not bother touching the
>>> firewall and let an admin do it, or prompt during cloud-setup-management.
>>>
>>> On Tue, May 12, 2015 at 10:32 AM, Rafael Fonseca <rsafonseca@gmail.com <ma...@gmail.com>>
>>> wrote:
>>>
>>>> And unfortunately, I don't think it's currently configurable even if you
>>>> change the config file.. it's hardcoded in:
>>>>
>>>> framework/cluster/src/com/cloud/cluster/ClusterServiceServletAdapter.java
>>>> framework/cluster/src/com/cloud/cluster/ClusterServiceServletImpl.java
>>>>
>>>> and in the firewall config in:
>>>> python/lib/cloudutils/serviceConfig.py
>>>>
>>>> needs to be rectified also :)
>>>>
>>>> The thing about cockpit is that it is enabled and on by default in the
>>> most
>>>> fedora 21, and might also be so for other distros with systemd in the
>>>> future, since it's a management interface for systemd.
>>>>
>>>>
>>>>
>>>> On Tue, May 12, 2015 at 7:21 PM, Rafael Fonseca <rsafonseca@gmail.com <ma...@gmail.com>>
>>>> wrote:
>>>>
>>>>>
>>>>> https://www.adminsub.net/tcp-udp-port-finder/9090 <https://www.adminsub.net/tcp-udp-port-finder/9090>
>>>>>
>>>>> vs
>>>>>
>>>>> https://www.adminsub.net/tcp-udp-port-finder/9190 <https://www.adminsub.net/tcp-udp-port-finder/9190>
>>>>>
>>>>> The latter would most likely hurt the less to a broad user base :)
>>>>>
>>>>> On Tue, May 12, 2015 at 7:20 PM, Rafael Fonseca <rsafonseca@gmail.com <ma...@gmail.com>>
>>>>> wrote:
>>>>>
>>>>>> There are some handy tools to get the sense of having likely issues
>>> with
>>>>>> other services :)
>>>>>>
>>>>>>
>>>>>> On Tue, May 12, 2015 at 7:15 PM, Marcus <shadowsor@gmail.com <ma...@gmail.com>> wrote:
>>>>>>
>>>>>>> I don't think we are recommending a reverse proxy (are we?), it was
>>>> just
>>>>>>> brought up as a solution if someone wants port 80 to go to
>>> cloudstack.
>>>>>>> At
>>>>>>> past jobs we put Apache on 80, and used it solely to host CS api docs
>>>> for
>>>>>>> the version of the API that the management server was running, as
>>> well
>>>>>>> as a
>>>>>>> few other utilities that were management server specific.
>>>>>>>
>>>>>>> Many shops also front CloudStack with a load balancer, in which case
>>>> they
>>>>>>> generally don't care what port it runs on.
>>>>>>>
>>>>>>> I'm not sure it's worth changing 9090, either, but I think it's less
>>> of
>>>>>>> an
>>>>>>> issue to do so. The best option is simply to make sure it is
>>>>>>> configurable,
>>>>>>> so in the event someone wants to run two services they can adjust the
>>>>>>> port
>>>>>>> (or use another IP). I don't know how many people care about or will
>>>> run
>>>>>>> cockpit, or any other service that will conflict on 8080, 9090, 8250
>>> or
>>>>>>> any
>>>>>>> other port we make up, and it seems like a losing battle to try to
>>>> guess
>>>>>>> that. In the end I guess I lean toward not inconveniencing our
>>> existing
>>>>>>> user base by changing ports, to avoid a minor and fairly expected
>>>>>>> inconvenience that a new setup might experience port conflicts with
>>>>>>> unrelated services on common app ports.
>>>>>>>
>>>>>>> On Tue, May 12, 2015 at 8:26 AM, Rafael Fonseca <
>>> rsafonseca@gmail.com <ma...@gmail.com>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> That is a good point David, but ideally, if we are recommending the
>>>>>>> use of
>>>>>>>> a reverse proxy because our out of the box solution isn't good
>>> enough
>>>>>>> for
>>>>>>>> production, i'd propose either:
>>>>>>>>
>>>>>>>> - Fix the performance problems with tomcat and make it production
>>>>>>> worthy
>>>>>>>> (in what concerns the application server, i'd say its better to
>>> have
>>>>>>> this
>>>>>>>> one locked down, to make sure user is using tested configs and lib
>>>>>>> versions
>>>>>>>> and to NOT depend on distro provided scripts, install locations,
>>>> libs,
>>>>>>> etc,
>>>>>>>> since this is a basic requirement to get things going);
>>>>>>>>
>>>>>>>> AND/OR
>>>>>>>>
>>>>>>>> - Suggest that a reverse proxy is recommended and provide automatic
>>>>>>>> configuration for the most common ones (like httpd and nginx) and
>>> not
>>>>>>>> necessarily have them shipped with the product.
>>>>>>>>
>>>>>>>> I'm usually also against providing locked configs, but ideally,
>>> there
>>>>>>>> should be some more automated sane defaults for a few things with
>>>>>>> OPTION to
>>>>>>>> change.. instead of just having to to everything by yourself if we
>>>>>>> don't
>>>>>>>> provide a default/automation .
>>>>>>>>
>>>>>>>> I'm keen with doing everything myself, but a lot of people aren't..
>>>>>>>>
>>>>>>>> I will also provide some fixes for performance soon, i've already
>>>>>>>> identified a few ;)
>>>>>>>>
>>>>>>>> :)
>>>>>>>>
>>>>>>>> On Tue, May 12, 2015 at 4:37 PM, David Nalley <david@gnsa.us <ma...@gnsa.us>>
>>> wrote:
>>>>>>>>
>>>>>>>>> On Tue, May 12, 2015 at 8:47 AM, Rafael Fonseca <
>>>>>>> rsafonseca@gmail.com <ma...@gmail.com>>
>>>>>>>>> wrote:
>>>>>>>>>> I'll stay away from touching port 80 for now, but isn't saving
>>>>>>> work to
>>>>>>>>> the
>>>>>>>>>> admin one of cloudstack's main goals?
>>>>>>>>>>
>>>>>>>>>> That is also the main reason to package this stuff and have
>>> rules
>>>>>>> for
>>>>>>>>>> configuration :)
>>>>>>>>>>
>>>>>>>>>> I do see a lot of people complaining that cloudstack is hard to
>>>>>>> setup
>>>>>>>> and
>>>>>>>>>> has very long setup guides and a lot of stuff doesn't work on
>>>>>>> certain
>>>>>>>>>> environments... i aim to put an end to that.. hopefully even
>>> the
>>>>>>>> dumbest
>>>>>>>>>> sysadmin will be able to get it up and running without much
>>>> effort
>>>>>>> by
>>>>>>>> the
>>>>>>>>>> time i'm done :) . The effort reduction is also always valid
>>> for
>>>>>>>>>> experienced sysadmins and developers ;)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Sorta - we want to do enough sanely that people can get going,
>>> but
>>>>>>> not
>>>>>>>>> so much that it locks people into specific configurations with no
>>>>>>>>> option to change them. If an nginx shop suddenly found httpd
>>>> deployed
>>>>>>>>> because of using CloudStack, well, that would be a surprise. We
>>>> don't
>>>>>>>>> really want it to be a black box.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, May 12, 2015 at 1:16 PM, Wido den Hollander <
>>>>>>> wido@widodh.nl>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>>>> Hash: SHA1
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 05/12/2015 12:03 PM, Rafael Fonseca wrote:
>>>>>>>>>>>> Wido,
>>>>>>>>>>>>
>>>>>>>>>>>> If we were to recommend proxying with httpd, shouldn't
>>>>>>> cloudstack
>>>>>>>>>>>> provide that as well out of the box?
>>>>>>>>>>>
>>>>>>>>>>> I'd stay away from that. Providing that out of the box means
>>>> doing
>>>>>>>>>>> more stuff which an admin should do.
>>>>>>>>>>>
>>>>>>>>>>> Wido
>>>>>>>>>>>
>>>>>>>>>>>> Btw, there isn't really a big performance gain by proxying
>>>>>>> through
>>>>>>>>>>>> httpd nowadays, the new version of the packaging also
>>> includes
>>>>>>>>>>>> using tomcat8, which has an improved http/nio connector,
>>> have
>>>> a
>>>>>>>>>>>> look here for some performance benchmarks :) ->
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>> http://www.tomcatexpert.com/blog/2010/03/24/myth-or-truth-one-should-a
>>>>>>>>>>> lways-use-apache-httpd-front-apache-tomcat-improve-perform
>>>>>>>>>>>>
>>>>>>>>>>>> What i think is that if we are going to suggest configuring
>>>>>>> httpd
>>>>>>>>>>>> on the same box we should do it automatically, if not,
>>> tomcat
>>>>>>> can
>>>>>>>>>>>> still run on port 80 by default and user can reverse proxy
>>>> from
>>>>>>> any
>>>>>>>>>>>> other machine :)
>>>>>>>>>>>>
>>>>>>>>>>>> Also, if we're sticking to tomcat, we should have scripts
>>>> build
>>>>>>>>>>>> the APR/native connector for improved performance :)
>>>>>>>>>>>> http://tomcat.apache.org/native-doc/
>>>>>>>>>>>>
>>>>>>>>>>>> This would be an improvement independent from using or not
>>>>>>>>>>>> httpd/nginx in front of tomcat.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, May 12, 2015 at 11:45 AM, Wido den Hollander
>>>>>>>>>>>> <wi...@widodh.nl> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 05/12/2015 11:37 AM, Erik Weber wrote:
>>>>>>>>>>>>>>> On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca
>>>>>>>>>>>>>>> <rs...@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm reworking the packaging system in cloudstack, and
>>>> would
>>>>>>>>>>>>>>>> like to gather your opinion on the following:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - Fedora 2x runs systemd's cockpit on port 9090 by
>>> default
>>>>>>>>>>>>>>>> This is a deal breaker for the cluster servlet port on
>>>> this
>>>>>>>>>>>>>>>> OS, the two possibilities would be to either pack
>>> changes
>>>>>>>>>>>>>>>> to fedora's config on rpm install or simply change the
>>>>>>>>>>>>>>>> servlet port to another one that does not clash on any
>>>>>>>>>>>>>>>> distro.. any comments/suggestions?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - Tomcat is not listening on port 80 Tomcat is using
>>> port
>>>>>>>>>>>>>>>> 8080, which makes the user have to specify that in the
>>>>>>>>>>>>>>>> browser.. should we change it? In ubuntu it's already
>>>>>>>>>>>>>>>> running under jsvc, so it shouldn't be a problem.. same
>>>> can
>>>>>>>>>>>>>>>> be arranged for centos/other distros.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Is it possible to ask the user for this during
>>> installation
>>>>>>>>>>>>>>> and default to either 80 or 8080? I know Debian has a way
>>>> to
>>>>>>>>>>>>>>> interact with the user during install, not sure about
>>>>>>>>>>>>>>> RedHat.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I don't know the rationale behind putting it on port 8080
>>>> in
>>>>>>>>>>>>>>> the first place, but personally I don't see a problem
>>>> moving
>>>>>>>>>>>>>>> it to port 80.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I'd say to stick to 8080 and recommend anybody to use
>>> Apache /
>>>>>>>>>>>> Nginx to proxy towards Tomcat.
>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - No link on the tomcat root (http://management-server/
>>>> can
>>>>>>>>>>>>>>>> link internally to http://management-server/client ,
>>> this
>>>>>>>>>>>>>>>> makes it easier for new users who don't know the URL for
>>>>>>>>>>>>>>>> the UI :)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sounds like a good idea to me, I always forget to add
>>>> /client
>>>>>>>>>>>>>>> when I browse to new installations.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>>>>>>> Version: GnuPG v1
>>>>>>>>>>>
>>>>>>>>>>>
>>> iQIcBAEBAgAGBQJVUeEFAAoJEAGbWC3bPspCupwQAJjU6Akq18N9QcPYiOK60NR5
>>>>>>>>>>>
>>> P9+MF0UFvu1N5nHJxYwEHjIqwuzN9957xqx6LK0nhyDMN8ECadvZXweT5XhXbh+5
>>>>>>>>>>>
>>> G7D1Wqilav7GqGiye+4zV2CLRUI8KBPrUMFHwk4C4o1SqE6YxiX7E8/WY+cx2nt2
>>>>>>>>>>>
>>> LRAwPIvc3IL5QRIbiDfFm19mJRExBvHIZCYsMAPMgag2p85HOzuGxQ/NCcME7nna
>>>>>>>>>>>
>>> ODlHkjrPaWF66vZtyMA289R1e0Bab7hbElirCsA0VoTP3gbrwNriDf1KSfmOzIJD
>>>>>>>>>>>
>>> VyaSq2kcDIrWYWjuXxtjhIKdxCCkopgqRvjjiEDCQ3LVDaMsh4PSjhl2SuSU24l4
>>>>>>>>>>>
>>> mX6DZXjnt+3U01FOj9Bc76K28hawB3+7qqYPEsWlboi7Jz5hn0j04Kn9wRa+ZbfF
>>>>>>>>>>>
>>> 8t1DUpdPDtWd+HsyV/fdKXKY1X4Q/P3SatrqVZBymnyT/l/ENvqYLzLcNXHN9NSl
>>>>>>>>>>>
>>> 8o0+vhmTJRdbK9QoNeB8QtmtU+VB4iyC6x5tfwgqLvRNsSep3mpEgrKVa3h1Ssaz
>>>>>>>>>>>
>>> 14ChxYSNktOLJM3JuKBHqzSM0lxOHOT7wkiSXiXlCpbaoVRLcge7U4PjJW/GCSrE
>>>>>>>>>>>
>>> a/BAUYQzSKBAS/OpZHFizmQ0J7ASXaFDlBwy5XBfV+4nZjtClVR4oN9VHAJJ8d2X
>>>>>>>>>>> Fl89s3wdH0L/ag6Sd/oj
>>>>>>>>>>> =nbJY
>>>>>>>>>>> -----END PGP SIGNATURE-----
>
Re: Cloudstack Repackaging / Distro support
Posted by Carlos Reátegui <cr...@gmail.com>.
How about having the installer check if 9090 is in use and ask for an alternative port if so.
I guess this would mean you first have to make the port configurable. During upgrades the check would not be made and leave the config as is.
> On May 12, 2015, at 2:09 PM, Rafael Fonseca <rs...@gmail.com> wrote:
>
> Marcus, it has not made it to CentOS/RedHat Server yet, but it's on Fedora
> Server, not desktop.. on by default.
>
> I can give a hand with those python scripts next week hopefully :)
>
> On Tue, May 12, 2015 at 9:04 PM, Marcus <shadowsor@gmail.com <ma...@gmail.com>> wrote:
>
>> I understand, but it's the sort of thing most admins will disable or remove
>> in their kickstart as a liability. RedHat has had default system management
>> services like this before and they were not well received (I forget the
>> name of the remote system management utility that shipped with RHEL4/5). If
>> it does make it from the desktop to the server as a default service though,
>> then I agree we will have to address it as a part of our CentOS management
>> server support.
>>
>> Don't get me started on the python config scripts, they've been a pain,
>> honestly. Particularly on the hypervisor side, it opens a bunch of ports
>> that not everyone needs, edits libvirt configs, and conflicts with
>> configuration management. They're great in the interest of someone spinning
>> up a quick proof of concept or small environment, but larger environments
>> usually manage their own configs and the python scripts touch all sorts of
>> things and require a post-agent reconfigure. If we make the ports
>> configurable, the script should probably just not bother touching the
>> firewall and let an admin do it, or prompt during cloud-setup-management.
>>
>> On Tue, May 12, 2015 at 10:32 AM, Rafael Fonseca <rsafonseca@gmail.com <ma...@gmail.com>>
>> wrote:
>>
>>> And unfortunately, I don't think it's currently configurable even if you
>>> change the config file.. it's hardcoded in:
>>>
>>> framework/cluster/src/com/cloud/cluster/ClusterServiceServletAdapter.java
>>> framework/cluster/src/com/cloud/cluster/ClusterServiceServletImpl.java
>>>
>>> and in the firewall config in:
>>> python/lib/cloudutils/serviceConfig.py
>>>
>>> needs to be rectified also :)
>>>
>>> The thing about cockpit is that it is enabled and on by default in the
>> most
>>> fedora 21, and might also be so for other distros with systemd in the
>>> future, since it's a management interface for systemd.
>>>
>>>
>>>
>>> On Tue, May 12, 2015 at 7:21 PM, Rafael Fonseca <rsafonseca@gmail.com <ma...@gmail.com>>
>>> wrote:
>>>
>>>>
>>>> https://www.adminsub.net/tcp-udp-port-finder/9090 <https://www.adminsub.net/tcp-udp-port-finder/9090>
>>>>
>>>> vs
>>>>
>>>> https://www.adminsub.net/tcp-udp-port-finder/9190 <https://www.adminsub.net/tcp-udp-port-finder/9190>
>>>>
>>>> The latter would most likely hurt the less to a broad user base :)
>>>>
>>>> On Tue, May 12, 2015 at 7:20 PM, Rafael Fonseca <rsafonseca@gmail.com <ma...@gmail.com>>
>>>> wrote:
>>>>
>>>>> There are some handy tools to get the sense of having likely issues
>> with
>>>>> other services :)
>>>>>
>>>>>
>>>>> On Tue, May 12, 2015 at 7:15 PM, Marcus <shadowsor@gmail.com <ma...@gmail.com>> wrote:
>>>>>
>>>>>> I don't think we are recommending a reverse proxy (are we?), it was
>>> just
>>>>>> brought up as a solution if someone wants port 80 to go to
>> cloudstack.
>>>>>> At
>>>>>> past jobs we put Apache on 80, and used it solely to host CS api docs
>>> for
>>>>>> the version of the API that the management server was running, as
>> well
>>>>>> as a
>>>>>> few other utilities that were management server specific.
>>>>>>
>>>>>> Many shops also front CloudStack with a load balancer, in which case
>>> they
>>>>>> generally don't care what port it runs on.
>>>>>>
>>>>>> I'm not sure it's worth changing 9090, either, but I think it's less
>> of
>>>>>> an
>>>>>> issue to do so. The best option is simply to make sure it is
>>>>>> configurable,
>>>>>> so in the event someone wants to run two services they can adjust the
>>>>>> port
>>>>>> (or use another IP). I don't know how many people care about or will
>>> run
>>>>>> cockpit, or any other service that will conflict on 8080, 9090, 8250
>> or
>>>>>> any
>>>>>> other port we make up, and it seems like a losing battle to try to
>>> guess
>>>>>> that. In the end I guess I lean toward not inconveniencing our
>> existing
>>>>>> user base by changing ports, to avoid a minor and fairly expected
>>>>>> inconvenience that a new setup might experience port conflicts with
>>>>>> unrelated services on common app ports.
>>>>>>
>>>>>> On Tue, May 12, 2015 at 8:26 AM, Rafael Fonseca <
>> rsafonseca@gmail.com <ma...@gmail.com>>
>>>>>> wrote:
>>>>>>
>>>>>>> That is a good point David, but ideally, if we are recommending the
>>>>>> use of
>>>>>>> a reverse proxy because our out of the box solution isn't good
>> enough
>>>>>> for
>>>>>>> production, i'd propose either:
>>>>>>>
>>>>>>> - Fix the performance problems with tomcat and make it production
>>>>>> worthy
>>>>>>> (in what concerns the application server, i'd say its better to
>> have
>>>>>> this
>>>>>>> one locked down, to make sure user is using tested configs and lib
>>>>>> versions
>>>>>>> and to NOT depend on distro provided scripts, install locations,
>>> libs,
>>>>>> etc,
>>>>>>> since this is a basic requirement to get things going);
>>>>>>>
>>>>>>> AND/OR
>>>>>>>
>>>>>>> - Suggest that a reverse proxy is recommended and provide automatic
>>>>>>> configuration for the most common ones (like httpd and nginx) and
>> not
>>>>>>> necessarily have them shipped with the product.
>>>>>>>
>>>>>>> I'm usually also against providing locked configs, but ideally,
>> there
>>>>>>> should be some more automated sane defaults for a few things with
>>>>>> OPTION to
>>>>>>> change.. instead of just having to to everything by yourself if we
>>>>>> don't
>>>>>>> provide a default/automation .
>>>>>>>
>>>>>>> I'm keen with doing everything myself, but a lot of people aren't..
>>>>>>>
>>>>>>> I will also provide some fixes for performance soon, i've already
>>>>>>> identified a few ;)
>>>>>>>
>>>>>>> :)
>>>>>>>
>>>>>>> On Tue, May 12, 2015 at 4:37 PM, David Nalley <david@gnsa.us <ma...@gnsa.us>>
>> wrote:
>>>>>>>
>>>>>>>> On Tue, May 12, 2015 at 8:47 AM, Rafael Fonseca <
>>>>>> rsafonseca@gmail.com <ma...@gmail.com>>
>>>>>>>> wrote:
>>>>>>>>> I'll stay away from touching port 80 for now, but isn't saving
>>>>>> work to
>>>>>>>> the
>>>>>>>>> admin one of cloudstack's main goals?
>>>>>>>>>
>>>>>>>>> That is also the main reason to package this stuff and have
>> rules
>>>>>> for
>>>>>>>>> configuration :)
>>>>>>>>>
>>>>>>>>> I do see a lot of people complaining that cloudstack is hard to
>>>>>> setup
>>>>>>> and
>>>>>>>>> has very long setup guides and a lot of stuff doesn't work on
>>>>>> certain
>>>>>>>>> environments... i aim to put an end to that.. hopefully even
>> the
>>>>>>> dumbest
>>>>>>>>> sysadmin will be able to get it up and running without much
>>> effort
>>>>>> by
>>>>>>> the
>>>>>>>>> time i'm done :) . The effort reduction is also always valid
>> for
>>>>>>>>> experienced sysadmins and developers ;)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Sorta - we want to do enough sanely that people can get going,
>> but
>>>>>> not
>>>>>>>> so much that it locks people into specific configurations with no
>>>>>>>> option to change them. If an nginx shop suddenly found httpd
>>> deployed
>>>>>>>> because of using CloudStack, well, that would be a surprise. We
>>> don't
>>>>>>>> really want it to be a black box.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, May 12, 2015 at 1:16 PM, Wido den Hollander <
>>>>>> wido@widodh.nl>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>>> Hash: SHA1
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 05/12/2015 12:03 PM, Rafael Fonseca wrote:
>>>>>>>>>>> Wido,
>>>>>>>>>>>
>>>>>>>>>>> If we were to recommend proxying with httpd, shouldn't
>>>>>> cloudstack
>>>>>>>>>>> provide that as well out of the box?
>>>>>>>>>>
>>>>>>>>>> I'd stay away from that. Providing that out of the box means
>>> doing
>>>>>>>>>> more stuff which an admin should do.
>>>>>>>>>>
>>>>>>>>>> Wido
>>>>>>>>>>
>>>>>>>>>>> Btw, there isn't really a big performance gain by proxying
>>>>>> through
>>>>>>>>>>> httpd nowadays, the new version of the packaging also
>> includes
>>>>>>>>>>> using tomcat8, which has an improved http/nio connector,
>> have
>>> a
>>>>>>>>>>> look here for some performance benchmarks :) ->
>>>>>>>>>>>
>>>>>>>>
>>>>>>
>> http://www.tomcatexpert.com/blog/2010/03/24/myth-or-truth-one-should-a
>>>>>>>>>> lways-use-apache-httpd-front-apache-tomcat-improve-perform
>>>>>>>>>>>
>>>>>>>>>>> What i think is that if we are going to suggest configuring
>>>>>> httpd
>>>>>>>>>>> on the same box we should do it automatically, if not,
>> tomcat
>>>>>> can
>>>>>>>>>>> still run on port 80 by default and user can reverse proxy
>>> from
>>>>>> any
>>>>>>>>>>> other machine :)
>>>>>>>>>>>
>>>>>>>>>>> Also, if we're sticking to tomcat, we should have scripts
>>> build
>>>>>>>>>>> the APR/native connector for improved performance :)
>>>>>>>>>>> http://tomcat.apache.org/native-doc/
>>>>>>>>>>>
>>>>>>>>>>> This would be an improvement independent from using or not
>>>>>>>>>>> httpd/nginx in front of tomcat.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, May 12, 2015 at 11:45 AM, Wido den Hollander
>>>>>>>>>>> <wi...@widodh.nl> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 05/12/2015 11:37 AM, Erik Weber wrote:
>>>>>>>>>>>>>> On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca
>>>>>>>>>>>>>> <rs...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm reworking the packaging system in cloudstack, and
>>> would
>>>>>>>>>>>>>>> like to gather your opinion on the following:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Fedora 2x runs systemd's cockpit on port 9090 by
>> default
>>>>>>>>>>>>>>> This is a deal breaker for the cluster servlet port on
>>> this
>>>>>>>>>>>>>>> OS, the two possibilities would be to either pack
>> changes
>>>>>>>>>>>>>>> to fedora's config on rpm install or simply change the
>>>>>>>>>>>>>>> servlet port to another one that does not clash on any
>>>>>>>>>>>>>>> distro.. any comments/suggestions?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Tomcat is not listening on port 80 Tomcat is using
>> port
>>>>>>>>>>>>>>> 8080, which makes the user have to specify that in the
>>>>>>>>>>>>>>> browser.. should we change it? In ubuntu it's already
>>>>>>>>>>>>>>> running under jsvc, so it shouldn't be a problem.. same
>>> can
>>>>>>>>>>>>>>> be arranged for centos/other distros.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is it possible to ask the user for this during
>> installation
>>>>>>>>>>>>>> and default to either 80 or 8080? I know Debian has a way
>>> to
>>>>>>>>>>>>>> interact with the user during install, not sure about
>>>>>>>>>>>>>> RedHat.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I don't know the rationale behind putting it on port 8080
>>> in
>>>>>>>>>>>>>> the first place, but personally I don't see a problem
>>> moving
>>>>>>>>>>>>>> it to port 80.
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I'd say to stick to 8080 and recommend anybody to use
>> Apache /
>>>>>>>>>>> Nginx to proxy towards Tomcat.
>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - No link on the tomcat root (http://management-server/
>>> can
>>>>>>>>>>>>>>> link internally to http://management-server/client ,
>> this
>>>>>>>>>>>>>>> makes it easier for new users who don't know the URL for
>>>>>>>>>>>>>>> the UI :)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sounds like a good idea to me, I always forget to add
>>> /client
>>>>>>>>>>>>>> when I browse to new installations.
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>>>>>> Version: GnuPG v1
>>>>>>>>>>
>>>>>>>>>>
>> iQIcBAEBAgAGBQJVUeEFAAoJEAGbWC3bPspCupwQAJjU6Akq18N9QcPYiOK60NR5
>>>>>>>>>>
>> P9+MF0UFvu1N5nHJxYwEHjIqwuzN9957xqx6LK0nhyDMN8ECadvZXweT5XhXbh+5
>>>>>>>>>>
>> G7D1Wqilav7GqGiye+4zV2CLRUI8KBPrUMFHwk4C4o1SqE6YxiX7E8/WY+cx2nt2
>>>>>>>>>>
>> LRAwPIvc3IL5QRIbiDfFm19mJRExBvHIZCYsMAPMgag2p85HOzuGxQ/NCcME7nna
>>>>>>>>>>
>> ODlHkjrPaWF66vZtyMA289R1e0Bab7hbElirCsA0VoTP3gbrwNriDf1KSfmOzIJD
>>>>>>>>>>
>> VyaSq2kcDIrWYWjuXxtjhIKdxCCkopgqRvjjiEDCQ3LVDaMsh4PSjhl2SuSU24l4
>>>>>>>>>>
>> mX6DZXjnt+3U01FOj9Bc76K28hawB3+7qqYPEsWlboi7Jz5hn0j04Kn9wRa+ZbfF
>>>>>>>>>>
>> 8t1DUpdPDtWd+HsyV/fdKXKY1X4Q/P3SatrqVZBymnyT/l/ENvqYLzLcNXHN9NSl
>>>>>>>>>>
>> 8o0+vhmTJRdbK9QoNeB8QtmtU+VB4iyC6x5tfwgqLvRNsSep3mpEgrKVa3h1Ssaz
>>>>>>>>>>
>> 14ChxYSNktOLJM3JuKBHqzSM0lxOHOT7wkiSXiXlCpbaoVRLcge7U4PjJW/GCSrE
>>>>>>>>>>
>> a/BAUYQzSKBAS/OpZHFizmQ0J7ASXaFDlBwy5XBfV+4nZjtClVR4oN9VHAJJ8d2X
>>>>>>>>>> Fl89s3wdH0L/ag6Sd/oj
>>>>>>>>>> =nbJY
>>>>>>>>>> -----END PGP SIGNATURE-----
Re: Cloudstack Repackaging / Distro support
Posted by Rafael Fonseca <rs...@gmail.com>.
Marcus, it has not made it to CentOS/RedHat Server yet, but it's on Fedora
Server, not desktop.. on by default.
I can give a hand with those python scripts next week hopefully :)
On Tue, May 12, 2015 at 9:04 PM, Marcus <sh...@gmail.com> wrote:
> I understand, but it's the sort of thing most admins will disable or remove
> in their kickstart as a liability. RedHat has had default system management
> services like this before and they were not well received (I forget the
> name of the remote system management utility that shipped with RHEL4/5). If
> it does make it from the desktop to the server as a default service though,
> then I agree we will have to address it as a part of our CentOS management
> server support.
>
> Don't get me started on the python config scripts, they've been a pain,
> honestly. Particularly on the hypervisor side, it opens a bunch of ports
> that not everyone needs, edits libvirt configs, and conflicts with
> configuration management. They're great in the interest of someone spinning
> up a quick proof of concept or small environment, but larger environments
> usually manage their own configs and the python scripts touch all sorts of
> things and require a post-agent reconfigure. If we make the ports
> configurable, the script should probably just not bother touching the
> firewall and let an admin do it, or prompt during cloud-setup-management.
>
> On Tue, May 12, 2015 at 10:32 AM, Rafael Fonseca <rs...@gmail.com>
> wrote:
>
> > And unfortunately, I don't think it's currently configurable even if you
> > change the config file.. it's hardcoded in:
> >
> > framework/cluster/src/com/cloud/cluster/ClusterServiceServletAdapter.java
> > framework/cluster/src/com/cloud/cluster/ClusterServiceServletImpl.java
> >
> > and in the firewall config in:
> > python/lib/cloudutils/serviceConfig.py
> >
> > needs to be rectified also :)
> >
> > The thing about cockpit is that it is enabled and on by default in the
> most
> > fedora 21, and might also be so for other distros with systemd in the
> > future, since it's a management interface for systemd.
> >
> >
> >
> > On Tue, May 12, 2015 at 7:21 PM, Rafael Fonseca <rs...@gmail.com>
> > wrote:
> >
> > >
> > > https://www.adminsub.net/tcp-udp-port-finder/9090
> > >
> > > vs
> > >
> > > https://www.adminsub.net/tcp-udp-port-finder/9190
> > >
> > > The latter would most likely hurt the less to a broad user base :)
> > >
> > > On Tue, May 12, 2015 at 7:20 PM, Rafael Fonseca <rs...@gmail.com>
> > > wrote:
> > >
> > >> There are some handy tools to get the sense of having likely issues
> with
> > >> other services :)
> > >>
> > >>
> > >> On Tue, May 12, 2015 at 7:15 PM, Marcus <sh...@gmail.com> wrote:
> > >>
> > >>> I don't think we are recommending a reverse proxy (are we?), it was
> > just
> > >>> brought up as a solution if someone wants port 80 to go to
> cloudstack.
> > >>> At
> > >>> past jobs we put Apache on 80, and used it solely to host CS api docs
> > for
> > >>> the version of the API that the management server was running, as
> well
> > >>> as a
> > >>> few other utilities that were management server specific.
> > >>>
> > >>> Many shops also front CloudStack with a load balancer, in which case
> > they
> > >>> generally don't care what port it runs on.
> > >>>
> > >>> I'm not sure it's worth changing 9090, either, but I think it's less
> of
> > >>> an
> > >>> issue to do so. The best option is simply to make sure it is
> > >>> configurable,
> > >>> so in the event someone wants to run two services they can adjust the
> > >>> port
> > >>> (or use another IP). I don't know how many people care about or will
> > run
> > >>> cockpit, or any other service that will conflict on 8080, 9090, 8250
> or
> > >>> any
> > >>> other port we make up, and it seems like a losing battle to try to
> > guess
> > >>> that. In the end I guess I lean toward not inconveniencing our
> existing
> > >>> user base by changing ports, to avoid a minor and fairly expected
> > >>> inconvenience that a new setup might experience port conflicts with
> > >>> unrelated services on common app ports.
> > >>>
> > >>> On Tue, May 12, 2015 at 8:26 AM, Rafael Fonseca <
> rsafonseca@gmail.com>
> > >>> wrote:
> > >>>
> > >>> > That is a good point David, but ideally, if we are recommending the
> > >>> use of
> > >>> > a reverse proxy because our out of the box solution isn't good
> enough
> > >>> for
> > >>> > production, i'd propose either:
> > >>> >
> > >>> > - Fix the performance problems with tomcat and make it production
> > >>> worthy
> > >>> > (in what concerns the application server, i'd say its better to
> have
> > >>> this
> > >>> > one locked down, to make sure user is using tested configs and lib
> > >>> versions
> > >>> > and to NOT depend on distro provided scripts, install locations,
> > libs,
> > >>> etc,
> > >>> > since this is a basic requirement to get things going);
> > >>> >
> > >>> > AND/OR
> > >>> >
> > >>> > - Suggest that a reverse proxy is recommended and provide automatic
> > >>> > configuration for the most common ones (like httpd and nginx) and
> not
> > >>> > necessarily have them shipped with the product.
> > >>> >
> > >>> > I'm usually also against providing locked configs, but ideally,
> there
> > >>> > should be some more automated sane defaults for a few things with
> > >>> OPTION to
> > >>> > change.. instead of just having to to everything by yourself if we
> > >>> don't
> > >>> > provide a default/automation .
> > >>> >
> > >>> > I'm keen with doing everything myself, but a lot of people aren't..
> > >>> >
> > >>> > I will also provide some fixes for performance soon, i've already
> > >>> > identified a few ;)
> > >>> >
> > >>> > :)
> > >>> >
> > >>> > On Tue, May 12, 2015 at 4:37 PM, David Nalley <da...@gnsa.us>
> wrote:
> > >>> >
> > >>> > > On Tue, May 12, 2015 at 8:47 AM, Rafael Fonseca <
> > >>> rsafonseca@gmail.com>
> > >>> > > wrote:
> > >>> > > > I'll stay away from touching port 80 for now, but isn't saving
> > >>> work to
> > >>> > > the
> > >>> > > > admin one of cloudstack's main goals?
> > >>> > > >
> > >>> > > > That is also the main reason to package this stuff and have
> rules
> > >>> for
> > >>> > > > configuration :)
> > >>> > > >
> > >>> > > > I do see a lot of people complaining that cloudstack is hard to
> > >>> setup
> > >>> > and
> > >>> > > > has very long setup guides and a lot of stuff doesn't work on
> > >>> certain
> > >>> > > > environments... i aim to put an end to that.. hopefully even
> the
> > >>> > dumbest
> > >>> > > > sysadmin will be able to get it up and running without much
> > effort
> > >>> by
> > >>> > the
> > >>> > > > time i'm done :) . The effort reduction is also always valid
> for
> > >>> > > > experienced sysadmins and developers ;)
> > >>> > > >
> > >>> > > >
> > >>> > >
> > >>> > > Sorta - we want to do enough sanely that people can get going,
> but
> > >>> not
> > >>> > > so much that it locks people into specific configurations with no
> > >>> > > option to change them. If an nginx shop suddenly found httpd
> > deployed
> > >>> > > because of using CloudStack, well, that would be a surprise. We
> > don't
> > >>> > > really want it to be a black box.
> > >>> > >
> > >>> > > >
> > >>> > > >
> > >>> > > > On Tue, May 12, 2015 at 1:16 PM, Wido den Hollander <
> > >>> wido@widodh.nl>
> > >>> > > wrote:
> > >>> > > >
> > >>> > > >> -----BEGIN PGP SIGNED MESSAGE-----
> > >>> > > >> Hash: SHA1
> > >>> > > >>
> > >>> > > >>
> > >>> > > >>
> > >>> > > >> On 05/12/2015 12:03 PM, Rafael Fonseca wrote:
> > >>> > > >> > Wido,
> > >>> > > >> >
> > >>> > > >> > If we were to recommend proxying with httpd, shouldn't
> > >>> cloudstack
> > >>> > > >> > provide that as well out of the box?
> > >>> > > >>
> > >>> > > >> I'd stay away from that. Providing that out of the box means
> > doing
> > >>> > > >> more stuff which an admin should do.
> > >>> > > >>
> > >>> > > >> Wido
> > >>> > > >>
> > >>> > > >> > Btw, there isn't really a big performance gain by proxying
> > >>> through
> > >>> > > >> > httpd nowadays, the new version of the packaging also
> includes
> > >>> > > >> > using tomcat8, which has an improved http/nio connector,
> have
> > a
> > >>> > > >> > look here for some performance benchmarks :) ->
> > >>> > > >> >
> > >>> > >
> > >>>
> http://www.tomcatexpert.com/blog/2010/03/24/myth-or-truth-one-should-a
> > >>> > > >> lways-use-apache-httpd-front-apache-tomcat-improve-perform
> > >>> > > >> >
> > >>> > > >> > What i think is that if we are going to suggest configuring
> > >>> httpd
> > >>> > > >> > on the same box we should do it automatically, if not,
> tomcat
> > >>> can
> > >>> > > >> > still run on port 80 by default and user can reverse proxy
> > from
> > >>> any
> > >>> > > >> > other machine :)
> > >>> > > >> >
> > >>> > > >> > Also, if we're sticking to tomcat, we should have scripts
> > build
> > >>> > > >> > the APR/native connector for improved performance :)
> > >>> > > >> > http://tomcat.apache.org/native-doc/
> > >>> > > >> >
> > >>> > > >> > This would be an improvement independent from using or not
> > >>> > > >> > httpd/nginx in front of tomcat.
> > >>> > > >> >
> > >>> > > >> >
> > >>> > > >> >
> > >>> > > >> >
> > >>> > > >> >
> > >>> > > >> > On Tue, May 12, 2015 at 11:45 AM, Wido den Hollander
> > >>> > > >> > <wi...@widodh.nl> wrote:
> > >>> > > >> >
> > >>> > > >> >
> > >>> > > >> >
> > >>> > > >> > On 05/12/2015 11:37 AM, Erik Weber wrote:
> > >>> > > >> >>>> On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca
> > >>> > > >> >>>> <rs...@gmail.com> wrote:
> > >>> > > >> >>>>
> > >>> > > >> >>>>> Hi all,
> > >>> > > >> >>>>>
> > >>> > > >> >>>>> I'm reworking the packaging system in cloudstack, and
> > would
> > >>> > > >> >>>>> like to gather your opinion on the following:
> > >>> > > >> >>>>>
> > >>> > > >> >>>>> - Fedora 2x runs systemd's cockpit on port 9090 by
> default
> > >>> > > >> >>>>> This is a deal breaker for the cluster servlet port on
> > this
> > >>> > > >> >>>>> OS, the two possibilities would be to either pack
> changes
> > >>> > > >> >>>>> to fedora's config on rpm install or simply change the
> > >>> > > >> >>>>> servlet port to another one that does not clash on any
> > >>> > > >> >>>>> distro.. any comments/suggestions?
> > >>> > > >> >>>>>
> > >>> > > >> >>>>> - Tomcat is not listening on port 80 Tomcat is using
> port
> > >>> > > >> >>>>> 8080, which makes the user have to specify that in the
> > >>> > > >> >>>>> browser.. should we change it? In ubuntu it's already
> > >>> > > >> >>>>> running under jsvc, so it shouldn't be a problem.. same
> > can
> > >>> > > >> >>>>> be arranged for centos/other distros.
> > >>> > > >> >>>>>
> > >>> > > >> >>>>
> > >>> > > >> >>>> Is it possible to ask the user for this during
> installation
> > >>> > > >> >>>> and default to either 80 or 8080? I know Debian has a way
> > to
> > >>> > > >> >>>> interact with the user during install, not sure about
> > >>> > > >> >>>> RedHat.
> > >>> > > >> >>>>
> > >>> > > >> >>>> I don't know the rationale behind putting it on port 8080
> > in
> > >>> > > >> >>>> the first place, but personally I don't see a problem
> > moving
> > >>> > > >> >>>> it to port 80.
> > >>> > > >> >>>>
> > >>> > > >> >
> > >>> > > >> > I'd say to stick to 8080 and recommend anybody to use
> Apache /
> > >>> > > >> > Nginx to proxy towards Tomcat.
> > >>> > > >> >
> > >>> > > >> >>>>
> > >>> > > >> >>>>> - No link on the tomcat root (http://management-server/
> > can
> > >>> > > >> >>>>> link internally to http://management-server/client ,
> this
> > >>> > > >> >>>>> makes it easier for new users who don't know the URL for
> > >>> > > >> >>>>> the UI :)
> > >>> > > >> >>>>>
> > >>> > > >> >>>>>
> > >>> > > >> >>>> Sounds like a good idea to me, I always forget to add
> > /client
> > >>> > > >> >>>> when I browse to new installations.
> > >>> > > >> >>>>
> > >>> > > >> >>
> > >>> > > >> >
> > >>> > > >> -----BEGIN PGP SIGNATURE-----
> > >>> > > >> Version: GnuPG v1
> > >>> > > >>
> > >>> > > >>
> iQIcBAEBAgAGBQJVUeEFAAoJEAGbWC3bPspCupwQAJjU6Akq18N9QcPYiOK60NR5
> > >>> > > >>
> P9+MF0UFvu1N5nHJxYwEHjIqwuzN9957xqx6LK0nhyDMN8ECadvZXweT5XhXbh+5
> > >>> > > >>
> G7D1Wqilav7GqGiye+4zV2CLRUI8KBPrUMFHwk4C4o1SqE6YxiX7E8/WY+cx2nt2
> > >>> > > >>
> LRAwPIvc3IL5QRIbiDfFm19mJRExBvHIZCYsMAPMgag2p85HOzuGxQ/NCcME7nna
> > >>> > > >>
> ODlHkjrPaWF66vZtyMA289R1e0Bab7hbElirCsA0VoTP3gbrwNriDf1KSfmOzIJD
> > >>> > > >>
> VyaSq2kcDIrWYWjuXxtjhIKdxCCkopgqRvjjiEDCQ3LVDaMsh4PSjhl2SuSU24l4
> > >>> > > >>
> mX6DZXjnt+3U01FOj9Bc76K28hawB3+7qqYPEsWlboi7Jz5hn0j04Kn9wRa+ZbfF
> > >>> > > >>
> 8t1DUpdPDtWd+HsyV/fdKXKY1X4Q/P3SatrqVZBymnyT/l/ENvqYLzLcNXHN9NSl
> > >>> > > >>
> 8o0+vhmTJRdbK9QoNeB8QtmtU+VB4iyC6x5tfwgqLvRNsSep3mpEgrKVa3h1Ssaz
> > >>> > > >>
> 14ChxYSNktOLJM3JuKBHqzSM0lxOHOT7wkiSXiXlCpbaoVRLcge7U4PjJW/GCSrE
> > >>> > > >>
> a/BAUYQzSKBAS/OpZHFizmQ0J7ASXaFDlBwy5XBfV+4nZjtClVR4oN9VHAJJ8d2X
> > >>> > > >> Fl89s3wdH0L/ag6Sd/oj
> > >>> > > >> =nbJY
> > >>> > > >> -----END PGP SIGNATURE-----
> > >>> > > >>
> > >>> > >
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>
Re: Cloudstack Repackaging / Distro support
Posted by Marcus <sh...@gmail.com>.
I understand, but it's the sort of thing most admins will disable or remove
in their kickstart as a liability. RedHat has had default system management
services like this before and they were not well received (I forget the
name of the remote system management utility that shipped with RHEL4/5). If
it does make it from the desktop to the server as a default service though,
then I agree we will have to address it as a part of our CentOS management
server support.
Don't get me started on the python config scripts, they've been a pain,
honestly. Particularly on the hypervisor side, it opens a bunch of ports
that not everyone needs, edits libvirt configs, and conflicts with
configuration management. They're great in the interest of someone spinning
up a quick proof of concept or small environment, but larger environments
usually manage their own configs and the python scripts touch all sorts of
things and require a post-agent reconfigure. If we make the ports
configurable, the script should probably just not bother touching the
firewall and let an admin do it, or prompt during cloud-setup-management.
On Tue, May 12, 2015 at 10:32 AM, Rafael Fonseca <rs...@gmail.com>
wrote:
> And unfortunately, I don't think it's currently configurable even if you
> change the config file.. it's hardcoded in:
>
> framework/cluster/src/com/cloud/cluster/ClusterServiceServletAdapter.java
> framework/cluster/src/com/cloud/cluster/ClusterServiceServletImpl.java
>
> and in the firewall config in:
> python/lib/cloudutils/serviceConfig.py
>
> needs to be rectified also :)
>
> The thing about cockpit is that it is enabled and on by default in the most
> fedora 21, and might also be so for other distros with systemd in the
> future, since it's a management interface for systemd.
>
>
>
> On Tue, May 12, 2015 at 7:21 PM, Rafael Fonseca <rs...@gmail.com>
> wrote:
>
> >
> > https://www.adminsub.net/tcp-udp-port-finder/9090
> >
> > vs
> >
> > https://www.adminsub.net/tcp-udp-port-finder/9190
> >
> > The latter would most likely hurt the less to a broad user base :)
> >
> > On Tue, May 12, 2015 at 7:20 PM, Rafael Fonseca <rs...@gmail.com>
> > wrote:
> >
> >> There are some handy tools to get the sense of having likely issues with
> >> other services :)
> >>
> >>
> >> On Tue, May 12, 2015 at 7:15 PM, Marcus <sh...@gmail.com> wrote:
> >>
> >>> I don't think we are recommending a reverse proxy (are we?), it was
> just
> >>> brought up as a solution if someone wants port 80 to go to cloudstack.
> >>> At
> >>> past jobs we put Apache on 80, and used it solely to host CS api docs
> for
> >>> the version of the API that the management server was running, as well
> >>> as a
> >>> few other utilities that were management server specific.
> >>>
> >>> Many shops also front CloudStack with a load balancer, in which case
> they
> >>> generally don't care what port it runs on.
> >>>
> >>> I'm not sure it's worth changing 9090, either, but I think it's less of
> >>> an
> >>> issue to do so. The best option is simply to make sure it is
> >>> configurable,
> >>> so in the event someone wants to run two services they can adjust the
> >>> port
> >>> (or use another IP). I don't know how many people care about or will
> run
> >>> cockpit, or any other service that will conflict on 8080, 9090, 8250 or
> >>> any
> >>> other port we make up, and it seems like a losing battle to try to
> guess
> >>> that. In the end I guess I lean toward not inconveniencing our existing
> >>> user base by changing ports, to avoid a minor and fairly expected
> >>> inconvenience that a new setup might experience port conflicts with
> >>> unrelated services on common app ports.
> >>>
> >>> On Tue, May 12, 2015 at 8:26 AM, Rafael Fonseca <rs...@gmail.com>
> >>> wrote:
> >>>
> >>> > That is a good point David, but ideally, if we are recommending the
> >>> use of
> >>> > a reverse proxy because our out of the box solution isn't good enough
> >>> for
> >>> > production, i'd propose either:
> >>> >
> >>> > - Fix the performance problems with tomcat and make it production
> >>> worthy
> >>> > (in what concerns the application server, i'd say its better to have
> >>> this
> >>> > one locked down, to make sure user is using tested configs and lib
> >>> versions
> >>> > and to NOT depend on distro provided scripts, install locations,
> libs,
> >>> etc,
> >>> > since this is a basic requirement to get things going);
> >>> >
> >>> > AND/OR
> >>> >
> >>> > - Suggest that a reverse proxy is recommended and provide automatic
> >>> > configuration for the most common ones (like httpd and nginx) and not
> >>> > necessarily have them shipped with the product.
> >>> >
> >>> > I'm usually also against providing locked configs, but ideally, there
> >>> > should be some more automated sane defaults for a few things with
> >>> OPTION to
> >>> > change.. instead of just having to to everything by yourself if we
> >>> don't
> >>> > provide a default/automation .
> >>> >
> >>> > I'm keen with doing everything myself, but a lot of people aren't..
> >>> >
> >>> > I will also provide some fixes for performance soon, i've already
> >>> > identified a few ;)
> >>> >
> >>> > :)
> >>> >
> >>> > On Tue, May 12, 2015 at 4:37 PM, David Nalley <da...@gnsa.us> wrote:
> >>> >
> >>> > > On Tue, May 12, 2015 at 8:47 AM, Rafael Fonseca <
> >>> rsafonseca@gmail.com>
> >>> > > wrote:
> >>> > > > I'll stay away from touching port 80 for now, but isn't saving
> >>> work to
> >>> > > the
> >>> > > > admin one of cloudstack's main goals?
> >>> > > >
> >>> > > > That is also the main reason to package this stuff and have rules
> >>> for
> >>> > > > configuration :)
> >>> > > >
> >>> > > > I do see a lot of people complaining that cloudstack is hard to
> >>> setup
> >>> > and
> >>> > > > has very long setup guides and a lot of stuff doesn't work on
> >>> certain
> >>> > > > environments... i aim to put an end to that.. hopefully even the
> >>> > dumbest
> >>> > > > sysadmin will be able to get it up and running without much
> effort
> >>> by
> >>> > the
> >>> > > > time i'm done :) . The effort reduction is also always valid for
> >>> > > > experienced sysadmins and developers ;)
> >>> > > >
> >>> > > >
> >>> > >
> >>> > > Sorta - we want to do enough sanely that people can get going, but
> >>> not
> >>> > > so much that it locks people into specific configurations with no
> >>> > > option to change them. If an nginx shop suddenly found httpd
> deployed
> >>> > > because of using CloudStack, well, that would be a surprise. We
> don't
> >>> > > really want it to be a black box.
> >>> > >
> >>> > > >
> >>> > > >
> >>> > > > On Tue, May 12, 2015 at 1:16 PM, Wido den Hollander <
> >>> wido@widodh.nl>
> >>> > > wrote:
> >>> > > >
> >>> > > >> -----BEGIN PGP SIGNED MESSAGE-----
> >>> > > >> Hash: SHA1
> >>> > > >>
> >>> > > >>
> >>> > > >>
> >>> > > >> On 05/12/2015 12:03 PM, Rafael Fonseca wrote:
> >>> > > >> > Wido,
> >>> > > >> >
> >>> > > >> > If we were to recommend proxying with httpd, shouldn't
> >>> cloudstack
> >>> > > >> > provide that as well out of the box?
> >>> > > >>
> >>> > > >> I'd stay away from that. Providing that out of the box means
> doing
> >>> > > >> more stuff which an admin should do.
> >>> > > >>
> >>> > > >> Wido
> >>> > > >>
> >>> > > >> > Btw, there isn't really a big performance gain by proxying
> >>> through
> >>> > > >> > httpd nowadays, the new version of the packaging also includes
> >>> > > >> > using tomcat8, which has an improved http/nio connector, have
> a
> >>> > > >> > look here for some performance benchmarks :) ->
> >>> > > >> >
> >>> > >
> >>> http://www.tomcatexpert.com/blog/2010/03/24/myth-or-truth-one-should-a
> >>> > > >> lways-use-apache-httpd-front-apache-tomcat-improve-perform
> >>> > > >> >
> >>> > > >> > What i think is that if we are going to suggest configuring
> >>> httpd
> >>> > > >> > on the same box we should do it automatically, if not, tomcat
> >>> can
> >>> > > >> > still run on port 80 by default and user can reverse proxy
> from
> >>> any
> >>> > > >> > other machine :)
> >>> > > >> >
> >>> > > >> > Also, if we're sticking to tomcat, we should have scripts
> build
> >>> > > >> > the APR/native connector for improved performance :)
> >>> > > >> > http://tomcat.apache.org/native-doc/
> >>> > > >> >
> >>> > > >> > This would be an improvement independent from using or not
> >>> > > >> > httpd/nginx in front of tomcat.
> >>> > > >> >
> >>> > > >> >
> >>> > > >> >
> >>> > > >> >
> >>> > > >> >
> >>> > > >> > On Tue, May 12, 2015 at 11:45 AM, Wido den Hollander
> >>> > > >> > <wi...@widodh.nl> wrote:
> >>> > > >> >
> >>> > > >> >
> >>> > > >> >
> >>> > > >> > On 05/12/2015 11:37 AM, Erik Weber wrote:
> >>> > > >> >>>> On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca
> >>> > > >> >>>> <rs...@gmail.com> wrote:
> >>> > > >> >>>>
> >>> > > >> >>>>> Hi all,
> >>> > > >> >>>>>
> >>> > > >> >>>>> I'm reworking the packaging system in cloudstack, and
> would
> >>> > > >> >>>>> like to gather your opinion on the following:
> >>> > > >> >>>>>
> >>> > > >> >>>>> - Fedora 2x runs systemd's cockpit on port 9090 by default
> >>> > > >> >>>>> This is a deal breaker for the cluster servlet port on
> this
> >>> > > >> >>>>> OS, the two possibilities would be to either pack changes
> >>> > > >> >>>>> to fedora's config on rpm install or simply change the
> >>> > > >> >>>>> servlet port to another one that does not clash on any
> >>> > > >> >>>>> distro.. any comments/suggestions?
> >>> > > >> >>>>>
> >>> > > >> >>>>> - Tomcat is not listening on port 80 Tomcat is using port
> >>> > > >> >>>>> 8080, which makes the user have to specify that in the
> >>> > > >> >>>>> browser.. should we change it? In ubuntu it's already
> >>> > > >> >>>>> running under jsvc, so it shouldn't be a problem.. same
> can
> >>> > > >> >>>>> be arranged for centos/other distros.
> >>> > > >> >>>>>
> >>> > > >> >>>>
> >>> > > >> >>>> Is it possible to ask the user for this during installation
> >>> > > >> >>>> and default to either 80 or 8080? I know Debian has a way
> to
> >>> > > >> >>>> interact with the user during install, not sure about
> >>> > > >> >>>> RedHat.
> >>> > > >> >>>>
> >>> > > >> >>>> I don't know the rationale behind putting it on port 8080
> in
> >>> > > >> >>>> the first place, but personally I don't see a problem
> moving
> >>> > > >> >>>> it to port 80.
> >>> > > >> >>>>
> >>> > > >> >
> >>> > > >> > I'd say to stick to 8080 and recommend anybody to use Apache /
> >>> > > >> > Nginx to proxy towards Tomcat.
> >>> > > >> >
> >>> > > >> >>>>
> >>> > > >> >>>>> - No link on the tomcat root (http://management-server/
> can
> >>> > > >> >>>>> link internally to http://management-server/client , this
> >>> > > >> >>>>> makes it easier for new users who don't know the URL for
> >>> > > >> >>>>> the UI :)
> >>> > > >> >>>>>
> >>> > > >> >>>>>
> >>> > > >> >>>> Sounds like a good idea to me, I always forget to add
> /client
> >>> > > >> >>>> when I browse to new installations.
> >>> > > >> >>>>
> >>> > > >> >>
> >>> > > >> >
> >>> > > >> -----BEGIN PGP SIGNATURE-----
> >>> > > >> Version: GnuPG v1
> >>> > > >>
> >>> > > >> iQIcBAEBAgAGBQJVUeEFAAoJEAGbWC3bPspCupwQAJjU6Akq18N9QcPYiOK60NR5
> >>> > > >> P9+MF0UFvu1N5nHJxYwEHjIqwuzN9957xqx6LK0nhyDMN8ECadvZXweT5XhXbh+5
> >>> > > >> G7D1Wqilav7GqGiye+4zV2CLRUI8KBPrUMFHwk4C4o1SqE6YxiX7E8/WY+cx2nt2
> >>> > > >> LRAwPIvc3IL5QRIbiDfFm19mJRExBvHIZCYsMAPMgag2p85HOzuGxQ/NCcME7nna
> >>> > > >> ODlHkjrPaWF66vZtyMA289R1e0Bab7hbElirCsA0VoTP3gbrwNriDf1KSfmOzIJD
> >>> > > >> VyaSq2kcDIrWYWjuXxtjhIKdxCCkopgqRvjjiEDCQ3LVDaMsh4PSjhl2SuSU24l4
> >>> > > >> mX6DZXjnt+3U01FOj9Bc76K28hawB3+7qqYPEsWlboi7Jz5hn0j04Kn9wRa+ZbfF
> >>> > > >> 8t1DUpdPDtWd+HsyV/fdKXKY1X4Q/P3SatrqVZBymnyT/l/ENvqYLzLcNXHN9NSl
> >>> > > >> 8o0+vhmTJRdbK9QoNeB8QtmtU+VB4iyC6x5tfwgqLvRNsSep3mpEgrKVa3h1Ssaz
> >>> > > >> 14ChxYSNktOLJM3JuKBHqzSM0lxOHOT7wkiSXiXlCpbaoVRLcge7U4PjJW/GCSrE
> >>> > > >> a/BAUYQzSKBAS/OpZHFizmQ0J7ASXaFDlBwy5XBfV+4nZjtClVR4oN9VHAJJ8d2X
> >>> > > >> Fl89s3wdH0L/ag6Sd/oj
> >>> > > >> =nbJY
> >>> > > >> -----END PGP SIGNATURE-----
> >>> > > >>
> >>> > >
> >>> >
> >>>
> >>
> >>
> >
>
Re: Cloudstack Repackaging / Distro support
Posted by Rafael Fonseca <rs...@gmail.com>.
And unfortunately, I don't think it's currently configurable even if you
change the config file.. it's hardcoded in:
framework/cluster/src/com/cloud/cluster/ClusterServiceServletAdapter.java
framework/cluster/src/com/cloud/cluster/ClusterServiceServletImpl.java
and in the firewall config in:
python/lib/cloudutils/serviceConfig.py
needs to be rectified also :)
The thing about cockpit is that it is enabled and on by default in the most
fedora 21, and might also be so for other distros with systemd in the
future, since it's a management interface for systemd.
On Tue, May 12, 2015 at 7:21 PM, Rafael Fonseca <rs...@gmail.com>
wrote:
>
> https://www.adminsub.net/tcp-udp-port-finder/9090
>
> vs
>
> https://www.adminsub.net/tcp-udp-port-finder/9190
>
> The latter would most likely hurt the less to a broad user base :)
>
> On Tue, May 12, 2015 at 7:20 PM, Rafael Fonseca <rs...@gmail.com>
> wrote:
>
>> There are some handy tools to get the sense of having likely issues with
>> other services :)
>>
>>
>> On Tue, May 12, 2015 at 7:15 PM, Marcus <sh...@gmail.com> wrote:
>>
>>> I don't think we are recommending a reverse proxy (are we?), it was just
>>> brought up as a solution if someone wants port 80 to go to cloudstack.
>>> At
>>> past jobs we put Apache on 80, and used it solely to host CS api docs for
>>> the version of the API that the management server was running, as well
>>> as a
>>> few other utilities that were management server specific.
>>>
>>> Many shops also front CloudStack with a load balancer, in which case they
>>> generally don't care what port it runs on.
>>>
>>> I'm not sure it's worth changing 9090, either, but I think it's less of
>>> an
>>> issue to do so. The best option is simply to make sure it is
>>> configurable,
>>> so in the event someone wants to run two services they can adjust the
>>> port
>>> (or use another IP). I don't know how many people care about or will run
>>> cockpit, or any other service that will conflict on 8080, 9090, 8250 or
>>> any
>>> other port we make up, and it seems like a losing battle to try to guess
>>> that. In the end I guess I lean toward not inconveniencing our existing
>>> user base by changing ports, to avoid a minor and fairly expected
>>> inconvenience that a new setup might experience port conflicts with
>>> unrelated services on common app ports.
>>>
>>> On Tue, May 12, 2015 at 8:26 AM, Rafael Fonseca <rs...@gmail.com>
>>> wrote:
>>>
>>> > That is a good point David, but ideally, if we are recommending the
>>> use of
>>> > a reverse proxy because our out of the box solution isn't good enough
>>> for
>>> > production, i'd propose either:
>>> >
>>> > - Fix the performance problems with tomcat and make it production
>>> worthy
>>> > (in what concerns the application server, i'd say its better to have
>>> this
>>> > one locked down, to make sure user is using tested configs and lib
>>> versions
>>> > and to NOT depend on distro provided scripts, install locations, libs,
>>> etc,
>>> > since this is a basic requirement to get things going);
>>> >
>>> > AND/OR
>>> >
>>> > - Suggest that a reverse proxy is recommended and provide automatic
>>> > configuration for the most common ones (like httpd and nginx) and not
>>> > necessarily have them shipped with the product.
>>> >
>>> > I'm usually also against providing locked configs, but ideally, there
>>> > should be some more automated sane defaults for a few things with
>>> OPTION to
>>> > change.. instead of just having to to everything by yourself if we
>>> don't
>>> > provide a default/automation .
>>> >
>>> > I'm keen with doing everything myself, but a lot of people aren't..
>>> >
>>> > I will also provide some fixes for performance soon, i've already
>>> > identified a few ;)
>>> >
>>> > :)
>>> >
>>> > On Tue, May 12, 2015 at 4:37 PM, David Nalley <da...@gnsa.us> wrote:
>>> >
>>> > > On Tue, May 12, 2015 at 8:47 AM, Rafael Fonseca <
>>> rsafonseca@gmail.com>
>>> > > wrote:
>>> > > > I'll stay away from touching port 80 for now, but isn't saving
>>> work to
>>> > > the
>>> > > > admin one of cloudstack's main goals?
>>> > > >
>>> > > > That is also the main reason to package this stuff and have rules
>>> for
>>> > > > configuration :)
>>> > > >
>>> > > > I do see a lot of people complaining that cloudstack is hard to
>>> setup
>>> > and
>>> > > > has very long setup guides and a lot of stuff doesn't work on
>>> certain
>>> > > > environments... i aim to put an end to that.. hopefully even the
>>> > dumbest
>>> > > > sysadmin will be able to get it up and running without much effort
>>> by
>>> > the
>>> > > > time i'm done :) . The effort reduction is also always valid for
>>> > > > experienced sysadmins and developers ;)
>>> > > >
>>> > > >
>>> > >
>>> > > Sorta - we want to do enough sanely that people can get going, but
>>> not
>>> > > so much that it locks people into specific configurations with no
>>> > > option to change them. If an nginx shop suddenly found httpd deployed
>>> > > because of using CloudStack, well, that would be a surprise. We don't
>>> > > really want it to be a black box.
>>> > >
>>> > > >
>>> > > >
>>> > > > On Tue, May 12, 2015 at 1:16 PM, Wido den Hollander <
>>> wido@widodh.nl>
>>> > > wrote:
>>> > > >
>>> > > >> -----BEGIN PGP SIGNED MESSAGE-----
>>> > > >> Hash: SHA1
>>> > > >>
>>> > > >>
>>> > > >>
>>> > > >> On 05/12/2015 12:03 PM, Rafael Fonseca wrote:
>>> > > >> > Wido,
>>> > > >> >
>>> > > >> > If we were to recommend proxying with httpd, shouldn't
>>> cloudstack
>>> > > >> > provide that as well out of the box?
>>> > > >>
>>> > > >> I'd stay away from that. Providing that out of the box means doing
>>> > > >> more stuff which an admin should do.
>>> > > >>
>>> > > >> Wido
>>> > > >>
>>> > > >> > Btw, there isn't really a big performance gain by proxying
>>> through
>>> > > >> > httpd nowadays, the new version of the packaging also includes
>>> > > >> > using tomcat8, which has an improved http/nio connector, have a
>>> > > >> > look here for some performance benchmarks :) ->
>>> > > >> >
>>> > >
>>> http://www.tomcatexpert.com/blog/2010/03/24/myth-or-truth-one-should-a
>>> > > >> lways-use-apache-httpd-front-apache-tomcat-improve-perform
>>> > > >> >
>>> > > >> > What i think is that if we are going to suggest configuring
>>> httpd
>>> > > >> > on the same box we should do it automatically, if not, tomcat
>>> can
>>> > > >> > still run on port 80 by default and user can reverse proxy from
>>> any
>>> > > >> > other machine :)
>>> > > >> >
>>> > > >> > Also, if we're sticking to tomcat, we should have scripts build
>>> > > >> > the APR/native connector for improved performance :)
>>> > > >> > http://tomcat.apache.org/native-doc/
>>> > > >> >
>>> > > >> > This would be an improvement independent from using or not
>>> > > >> > httpd/nginx in front of tomcat.
>>> > > >> >
>>> > > >> >
>>> > > >> >
>>> > > >> >
>>> > > >> >
>>> > > >> > On Tue, May 12, 2015 at 11:45 AM, Wido den Hollander
>>> > > >> > <wi...@widodh.nl> wrote:
>>> > > >> >
>>> > > >> >
>>> > > >> >
>>> > > >> > On 05/12/2015 11:37 AM, Erik Weber wrote:
>>> > > >> >>>> On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca
>>> > > >> >>>> <rs...@gmail.com> wrote:
>>> > > >> >>>>
>>> > > >> >>>>> Hi all,
>>> > > >> >>>>>
>>> > > >> >>>>> I'm reworking the packaging system in cloudstack, and would
>>> > > >> >>>>> like to gather your opinion on the following:
>>> > > >> >>>>>
>>> > > >> >>>>> - Fedora 2x runs systemd's cockpit on port 9090 by default
>>> > > >> >>>>> This is a deal breaker for the cluster servlet port on this
>>> > > >> >>>>> OS, the two possibilities would be to either pack changes
>>> > > >> >>>>> to fedora's config on rpm install or simply change the
>>> > > >> >>>>> servlet port to another one that does not clash on any
>>> > > >> >>>>> distro.. any comments/suggestions?
>>> > > >> >>>>>
>>> > > >> >>>>> - Tomcat is not listening on port 80 Tomcat is using port
>>> > > >> >>>>> 8080, which makes the user have to specify that in the
>>> > > >> >>>>> browser.. should we change it? In ubuntu it's already
>>> > > >> >>>>> running under jsvc, so it shouldn't be a problem.. same can
>>> > > >> >>>>> be arranged for centos/other distros.
>>> > > >> >>>>>
>>> > > >> >>>>
>>> > > >> >>>> Is it possible to ask the user for this during installation
>>> > > >> >>>> and default to either 80 or 8080? I know Debian has a way to
>>> > > >> >>>> interact with the user during install, not sure about
>>> > > >> >>>> RedHat.
>>> > > >> >>>>
>>> > > >> >>>> I don't know the rationale behind putting it on port 8080 in
>>> > > >> >>>> the first place, but personally I don't see a problem moving
>>> > > >> >>>> it to port 80.
>>> > > >> >>>>
>>> > > >> >
>>> > > >> > I'd say to stick to 8080 and recommend anybody to use Apache /
>>> > > >> > Nginx to proxy towards Tomcat.
>>> > > >> >
>>> > > >> >>>>
>>> > > >> >>>>> - No link on the tomcat root (http://management-server/ can
>>> > > >> >>>>> link internally to http://management-server/client , this
>>> > > >> >>>>> makes it easier for new users who don't know the URL for
>>> > > >> >>>>> the UI :)
>>> > > >> >>>>>
>>> > > >> >>>>>
>>> > > >> >>>> Sounds like a good idea to me, I always forget to add /client
>>> > > >> >>>> when I browse to new installations.
>>> > > >> >>>>
>>> > > >> >>
>>> > > >> >
>>> > > >> -----BEGIN PGP SIGNATURE-----
>>> > > >> Version: GnuPG v1
>>> > > >>
>>> > > >> iQIcBAEBAgAGBQJVUeEFAAoJEAGbWC3bPspCupwQAJjU6Akq18N9QcPYiOK60NR5
>>> > > >> P9+MF0UFvu1N5nHJxYwEHjIqwuzN9957xqx6LK0nhyDMN8ECadvZXweT5XhXbh+5
>>> > > >> G7D1Wqilav7GqGiye+4zV2CLRUI8KBPrUMFHwk4C4o1SqE6YxiX7E8/WY+cx2nt2
>>> > > >> LRAwPIvc3IL5QRIbiDfFm19mJRExBvHIZCYsMAPMgag2p85HOzuGxQ/NCcME7nna
>>> > > >> ODlHkjrPaWF66vZtyMA289R1e0Bab7hbElirCsA0VoTP3gbrwNriDf1KSfmOzIJD
>>> > > >> VyaSq2kcDIrWYWjuXxtjhIKdxCCkopgqRvjjiEDCQ3LVDaMsh4PSjhl2SuSU24l4
>>> > > >> mX6DZXjnt+3U01FOj9Bc76K28hawB3+7qqYPEsWlboi7Jz5hn0j04Kn9wRa+ZbfF
>>> > > >> 8t1DUpdPDtWd+HsyV/fdKXKY1X4Q/P3SatrqVZBymnyT/l/ENvqYLzLcNXHN9NSl
>>> > > >> 8o0+vhmTJRdbK9QoNeB8QtmtU+VB4iyC6x5tfwgqLvRNsSep3mpEgrKVa3h1Ssaz
>>> > > >> 14ChxYSNktOLJM3JuKBHqzSM0lxOHOT7wkiSXiXlCpbaoVRLcge7U4PjJW/GCSrE
>>> > > >> a/BAUYQzSKBAS/OpZHFizmQ0J7ASXaFDlBwy5XBfV+4nZjtClVR4oN9VHAJJ8d2X
>>> > > >> Fl89s3wdH0L/ag6Sd/oj
>>> > > >> =nbJY
>>> > > >> -----END PGP SIGNATURE-----
>>> > > >>
>>> > >
>>> >
>>>
>>
>>
>
Re: Cloudstack Repackaging / Distro support
Posted by Rafael Fonseca <rs...@gmail.com>.
https://www.adminsub.net/tcp-udp-port-finder/9090
vs
https://www.adminsub.net/tcp-udp-port-finder/9190
The latter would most likely hurt the less to a broad user base :)
On Tue, May 12, 2015 at 7:20 PM, Rafael Fonseca <rs...@gmail.com>
wrote:
> There are some handy tools to get the sense of having likely issues with
> other services :)
>
>
> On Tue, May 12, 2015 at 7:15 PM, Marcus <sh...@gmail.com> wrote:
>
>> I don't think we are recommending a reverse proxy (are we?), it was just
>> brought up as a solution if someone wants port 80 to go to cloudstack. At
>> past jobs we put Apache on 80, and used it solely to host CS api docs for
>> the version of the API that the management server was running, as well as
>> a
>> few other utilities that were management server specific.
>>
>> Many shops also front CloudStack with a load balancer, in which case they
>> generally don't care what port it runs on.
>>
>> I'm not sure it's worth changing 9090, either, but I think it's less of an
>> issue to do so. The best option is simply to make sure it is
>> configurable,
>> so in the event someone wants to run two services they can adjust the port
>> (or use another IP). I don't know how many people care about or will run
>> cockpit, or any other service that will conflict on 8080, 9090, 8250 or
>> any
>> other port we make up, and it seems like a losing battle to try to guess
>> that. In the end I guess I lean toward not inconveniencing our existing
>> user base by changing ports, to avoid a minor and fairly expected
>> inconvenience that a new setup might experience port conflicts with
>> unrelated services on common app ports.
>>
>> On Tue, May 12, 2015 at 8:26 AM, Rafael Fonseca <rs...@gmail.com>
>> wrote:
>>
>> > That is a good point David, but ideally, if we are recommending the use
>> of
>> > a reverse proxy because our out of the box solution isn't good enough
>> for
>> > production, i'd propose either:
>> >
>> > - Fix the performance problems with tomcat and make it production worthy
>> > (in what concerns the application server, i'd say its better to have
>> this
>> > one locked down, to make sure user is using tested configs and lib
>> versions
>> > and to NOT depend on distro provided scripts, install locations, libs,
>> etc,
>> > since this is a basic requirement to get things going);
>> >
>> > AND/OR
>> >
>> > - Suggest that a reverse proxy is recommended and provide automatic
>> > configuration for the most common ones (like httpd and nginx) and not
>> > necessarily have them shipped with the product.
>> >
>> > I'm usually also against providing locked configs, but ideally, there
>> > should be some more automated sane defaults for a few things with
>> OPTION to
>> > change.. instead of just having to to everything by yourself if we don't
>> > provide a default/automation .
>> >
>> > I'm keen with doing everything myself, but a lot of people aren't..
>> >
>> > I will also provide some fixes for performance soon, i've already
>> > identified a few ;)
>> >
>> > :)
>> >
>> > On Tue, May 12, 2015 at 4:37 PM, David Nalley <da...@gnsa.us> wrote:
>> >
>> > > On Tue, May 12, 2015 at 8:47 AM, Rafael Fonseca <rsafonseca@gmail.com
>> >
>> > > wrote:
>> > > > I'll stay away from touching port 80 for now, but isn't saving work
>> to
>> > > the
>> > > > admin one of cloudstack's main goals?
>> > > >
>> > > > That is also the main reason to package this stuff and have rules
>> for
>> > > > configuration :)
>> > > >
>> > > > I do see a lot of people complaining that cloudstack is hard to
>> setup
>> > and
>> > > > has very long setup guides and a lot of stuff doesn't work on
>> certain
>> > > > environments... i aim to put an end to that.. hopefully even the
>> > dumbest
>> > > > sysadmin will be able to get it up and running without much effort
>> by
>> > the
>> > > > time i'm done :) . The effort reduction is also always valid for
>> > > > experienced sysadmins and developers ;)
>> > > >
>> > > >
>> > >
>> > > Sorta - we want to do enough sanely that people can get going, but not
>> > > so much that it locks people into specific configurations with no
>> > > option to change them. If an nginx shop suddenly found httpd deployed
>> > > because of using CloudStack, well, that would be a surprise. We don't
>> > > really want it to be a black box.
>> > >
>> > > >
>> > > >
>> > > > On Tue, May 12, 2015 at 1:16 PM, Wido den Hollander <wido@widodh.nl
>> >
>> > > wrote:
>> > > >
>> > > >> -----BEGIN PGP SIGNED MESSAGE-----
>> > > >> Hash: SHA1
>> > > >>
>> > > >>
>> > > >>
>> > > >> On 05/12/2015 12:03 PM, Rafael Fonseca wrote:
>> > > >> > Wido,
>> > > >> >
>> > > >> > If we were to recommend proxying with httpd, shouldn't cloudstack
>> > > >> > provide that as well out of the box?
>> > > >>
>> > > >> I'd stay away from that. Providing that out of the box means doing
>> > > >> more stuff which an admin should do.
>> > > >>
>> > > >> Wido
>> > > >>
>> > > >> > Btw, there isn't really a big performance gain by proxying
>> through
>> > > >> > httpd nowadays, the new version of the packaging also includes
>> > > >> > using tomcat8, which has an improved http/nio connector, have a
>> > > >> > look here for some performance benchmarks :) ->
>> > > >> >
>> > >
>> http://www.tomcatexpert.com/blog/2010/03/24/myth-or-truth-one-should-a
>> > > >> lways-use-apache-httpd-front-apache-tomcat-improve-perform
>> > > >> >
>> > > >> > What i think is that if we are going to suggest configuring
>> httpd
>> > > >> > on the same box we should do it automatically, if not, tomcat can
>> > > >> > still run on port 80 by default and user can reverse proxy from
>> any
>> > > >> > other machine :)
>> > > >> >
>> > > >> > Also, if we're sticking to tomcat, we should have scripts build
>> > > >> > the APR/native connector for improved performance :)
>> > > >> > http://tomcat.apache.org/native-doc/
>> > > >> >
>> > > >> > This would be an improvement independent from using or not
>> > > >> > httpd/nginx in front of tomcat.
>> > > >> >
>> > > >> >
>> > > >> >
>> > > >> >
>> > > >> >
>> > > >> > On Tue, May 12, 2015 at 11:45 AM, Wido den Hollander
>> > > >> > <wi...@widodh.nl> wrote:
>> > > >> >
>> > > >> >
>> > > >> >
>> > > >> > On 05/12/2015 11:37 AM, Erik Weber wrote:
>> > > >> >>>> On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca
>> > > >> >>>> <rs...@gmail.com> wrote:
>> > > >> >>>>
>> > > >> >>>>> Hi all,
>> > > >> >>>>>
>> > > >> >>>>> I'm reworking the packaging system in cloudstack, and would
>> > > >> >>>>> like to gather your opinion on the following:
>> > > >> >>>>>
>> > > >> >>>>> - Fedora 2x runs systemd's cockpit on port 9090 by default
>> > > >> >>>>> This is a deal breaker for the cluster servlet port on this
>> > > >> >>>>> OS, the two possibilities would be to either pack changes
>> > > >> >>>>> to fedora's config on rpm install or simply change the
>> > > >> >>>>> servlet port to another one that does not clash on any
>> > > >> >>>>> distro.. any comments/suggestions?
>> > > >> >>>>>
>> > > >> >>>>> - Tomcat is not listening on port 80 Tomcat is using port
>> > > >> >>>>> 8080, which makes the user have to specify that in the
>> > > >> >>>>> browser.. should we change it? In ubuntu it's already
>> > > >> >>>>> running under jsvc, so it shouldn't be a problem.. same can
>> > > >> >>>>> be arranged for centos/other distros.
>> > > >> >>>>>
>> > > >> >>>>
>> > > >> >>>> Is it possible to ask the user for this during installation
>> > > >> >>>> and default to either 80 or 8080? I know Debian has a way to
>> > > >> >>>> interact with the user during install, not sure about
>> > > >> >>>> RedHat.
>> > > >> >>>>
>> > > >> >>>> I don't know the rationale behind putting it on port 8080 in
>> > > >> >>>> the first place, but personally I don't see a problem moving
>> > > >> >>>> it to port 80.
>> > > >> >>>>
>> > > >> >
>> > > >> > I'd say to stick to 8080 and recommend anybody to use Apache /
>> > > >> > Nginx to proxy towards Tomcat.
>> > > >> >
>> > > >> >>>>
>> > > >> >>>>> - No link on the tomcat root (http://management-server/ can
>> > > >> >>>>> link internally to http://management-server/client , this
>> > > >> >>>>> makes it easier for new users who don't know the URL for
>> > > >> >>>>> the UI :)
>> > > >> >>>>>
>> > > >> >>>>>
>> > > >> >>>> Sounds like a good idea to me, I always forget to add /client
>> > > >> >>>> when I browse to new installations.
>> > > >> >>>>
>> > > >> >>
>> > > >> >
>> > > >> -----BEGIN PGP SIGNATURE-----
>> > > >> Version: GnuPG v1
>> > > >>
>> > > >> iQIcBAEBAgAGBQJVUeEFAAoJEAGbWC3bPspCupwQAJjU6Akq18N9QcPYiOK60NR5
>> > > >> P9+MF0UFvu1N5nHJxYwEHjIqwuzN9957xqx6LK0nhyDMN8ECadvZXweT5XhXbh+5
>> > > >> G7D1Wqilav7GqGiye+4zV2CLRUI8KBPrUMFHwk4C4o1SqE6YxiX7E8/WY+cx2nt2
>> > > >> LRAwPIvc3IL5QRIbiDfFm19mJRExBvHIZCYsMAPMgag2p85HOzuGxQ/NCcME7nna
>> > > >> ODlHkjrPaWF66vZtyMA289R1e0Bab7hbElirCsA0VoTP3gbrwNriDf1KSfmOzIJD
>> > > >> VyaSq2kcDIrWYWjuXxtjhIKdxCCkopgqRvjjiEDCQ3LVDaMsh4PSjhl2SuSU24l4
>> > > >> mX6DZXjnt+3U01FOj9Bc76K28hawB3+7qqYPEsWlboi7Jz5hn0j04Kn9wRa+ZbfF
>> > > >> 8t1DUpdPDtWd+HsyV/fdKXKY1X4Q/P3SatrqVZBymnyT/l/ENvqYLzLcNXHN9NSl
>> > > >> 8o0+vhmTJRdbK9QoNeB8QtmtU+VB4iyC6x5tfwgqLvRNsSep3mpEgrKVa3h1Ssaz
>> > > >> 14ChxYSNktOLJM3JuKBHqzSM0lxOHOT7wkiSXiXlCpbaoVRLcge7U4PjJW/GCSrE
>> > > >> a/BAUYQzSKBAS/OpZHFizmQ0J7ASXaFDlBwy5XBfV+4nZjtClVR4oN9VHAJJ8d2X
>> > > >> Fl89s3wdH0L/ag6Sd/oj
>> > > >> =nbJY
>> > > >> -----END PGP SIGNATURE-----
>> > > >>
>> > >
>> >
>>
>
>
Re: Cloudstack Repackaging / Distro support
Posted by Rafael Fonseca <rs...@gmail.com>.
There are some handy tools to get the sense of having likely issues with
other services :)
On Tue, May 12, 2015 at 7:15 PM, Marcus <sh...@gmail.com> wrote:
> I don't think we are recommending a reverse proxy (are we?), it was just
> brought up as a solution if someone wants port 80 to go to cloudstack. At
> past jobs we put Apache on 80, and used it solely to host CS api docs for
> the version of the API that the management server was running, as well as a
> few other utilities that were management server specific.
>
> Many shops also front CloudStack with a load balancer, in which case they
> generally don't care what port it runs on.
>
> I'm not sure it's worth changing 9090, either, but I think it's less of an
> issue to do so. The best option is simply to make sure it is configurable,
> so in the event someone wants to run two services they can adjust the port
> (or use another IP). I don't know how many people care about or will run
> cockpit, or any other service that will conflict on 8080, 9090, 8250 or any
> other port we make up, and it seems like a losing battle to try to guess
> that. In the end I guess I lean toward not inconveniencing our existing
> user base by changing ports, to avoid a minor and fairly expected
> inconvenience that a new setup might experience port conflicts with
> unrelated services on common app ports.
>
> On Tue, May 12, 2015 at 8:26 AM, Rafael Fonseca <rs...@gmail.com>
> wrote:
>
> > That is a good point David, but ideally, if we are recommending the use
> of
> > a reverse proxy because our out of the box solution isn't good enough for
> > production, i'd propose either:
> >
> > - Fix the performance problems with tomcat and make it production worthy
> > (in what concerns the application server, i'd say its better to have this
> > one locked down, to make sure user is using tested configs and lib
> versions
> > and to NOT depend on distro provided scripts, install locations, libs,
> etc,
> > since this is a basic requirement to get things going);
> >
> > AND/OR
> >
> > - Suggest that a reverse proxy is recommended and provide automatic
> > configuration for the most common ones (like httpd and nginx) and not
> > necessarily have them shipped with the product.
> >
> > I'm usually also against providing locked configs, but ideally, there
> > should be some more automated sane defaults for a few things with OPTION
> to
> > change.. instead of just having to to everything by yourself if we don't
> > provide a default/automation .
> >
> > I'm keen with doing everything myself, but a lot of people aren't..
> >
> > I will also provide some fixes for performance soon, i've already
> > identified a few ;)
> >
> > :)
> >
> > On Tue, May 12, 2015 at 4:37 PM, David Nalley <da...@gnsa.us> wrote:
> >
> > > On Tue, May 12, 2015 at 8:47 AM, Rafael Fonseca <rs...@gmail.com>
> > > wrote:
> > > > I'll stay away from touching port 80 for now, but isn't saving work
> to
> > > the
> > > > admin one of cloudstack's main goals?
> > > >
> > > > That is also the main reason to package this stuff and have rules for
> > > > configuration :)
> > > >
> > > > I do see a lot of people complaining that cloudstack is hard to setup
> > and
> > > > has very long setup guides and a lot of stuff doesn't work on certain
> > > > environments... i aim to put an end to that.. hopefully even the
> > dumbest
> > > > sysadmin will be able to get it up and running without much effort by
> > the
> > > > time i'm done :) . The effort reduction is also always valid for
> > > > experienced sysadmins and developers ;)
> > > >
> > > >
> > >
> > > Sorta - we want to do enough sanely that people can get going, but not
> > > so much that it locks people into specific configurations with no
> > > option to change them. If an nginx shop suddenly found httpd deployed
> > > because of using CloudStack, well, that would be a surprise. We don't
> > > really want it to be a black box.
> > >
> > > >
> > > >
> > > > On Tue, May 12, 2015 at 1:16 PM, Wido den Hollander <wi...@widodh.nl>
> > > wrote:
> > > >
> > > >> -----BEGIN PGP SIGNED MESSAGE-----
> > > >> Hash: SHA1
> > > >>
> > > >>
> > > >>
> > > >> On 05/12/2015 12:03 PM, Rafael Fonseca wrote:
> > > >> > Wido,
> > > >> >
> > > >> > If we were to recommend proxying with httpd, shouldn't cloudstack
> > > >> > provide that as well out of the box?
> > > >>
> > > >> I'd stay away from that. Providing that out of the box means doing
> > > >> more stuff which an admin should do.
> > > >>
> > > >> Wido
> > > >>
> > > >> > Btw, there isn't really a big performance gain by proxying through
> > > >> > httpd nowadays, the new version of the packaging also includes
> > > >> > using tomcat8, which has an improved http/nio connector, have a
> > > >> > look here for some performance benchmarks :) ->
> > > >> >
> > > http://www.tomcatexpert.com/blog/2010/03/24/myth-or-truth-one-should-a
> > > >> lways-use-apache-httpd-front-apache-tomcat-improve-perform
> > > >> >
> > > >> > What i think is that if we are going to suggest configuring httpd
> > > >> > on the same box we should do it automatically, if not, tomcat can
> > > >> > still run on port 80 by default and user can reverse proxy from
> any
> > > >> > other machine :)
> > > >> >
> > > >> > Also, if we're sticking to tomcat, we should have scripts build
> > > >> > the APR/native connector for improved performance :)
> > > >> > http://tomcat.apache.org/native-doc/
> > > >> >
> > > >> > This would be an improvement independent from using or not
> > > >> > httpd/nginx in front of tomcat.
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Tue, May 12, 2015 at 11:45 AM, Wido den Hollander
> > > >> > <wi...@widodh.nl> wrote:
> > > >> >
> > > >> >
> > > >> >
> > > >> > On 05/12/2015 11:37 AM, Erik Weber wrote:
> > > >> >>>> On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca
> > > >> >>>> <rs...@gmail.com> wrote:
> > > >> >>>>
> > > >> >>>>> Hi all,
> > > >> >>>>>
> > > >> >>>>> I'm reworking the packaging system in cloudstack, and would
> > > >> >>>>> like to gather your opinion on the following:
> > > >> >>>>>
> > > >> >>>>> - Fedora 2x runs systemd's cockpit on port 9090 by default
> > > >> >>>>> This is a deal breaker for the cluster servlet port on this
> > > >> >>>>> OS, the two possibilities would be to either pack changes
> > > >> >>>>> to fedora's config on rpm install or simply change the
> > > >> >>>>> servlet port to another one that does not clash on any
> > > >> >>>>> distro.. any comments/suggestions?
> > > >> >>>>>
> > > >> >>>>> - Tomcat is not listening on port 80 Tomcat is using port
> > > >> >>>>> 8080, which makes the user have to specify that in the
> > > >> >>>>> browser.. should we change it? In ubuntu it's already
> > > >> >>>>> running under jsvc, so it shouldn't be a problem.. same can
> > > >> >>>>> be arranged for centos/other distros.
> > > >> >>>>>
> > > >> >>>>
> > > >> >>>> Is it possible to ask the user for this during installation
> > > >> >>>> and default to either 80 or 8080? I know Debian has a way to
> > > >> >>>> interact with the user during install, not sure about
> > > >> >>>> RedHat.
> > > >> >>>>
> > > >> >>>> I don't know the rationale behind putting it on port 8080 in
> > > >> >>>> the first place, but personally I don't see a problem moving
> > > >> >>>> it to port 80.
> > > >> >>>>
> > > >> >
> > > >> > I'd say to stick to 8080 and recommend anybody to use Apache /
> > > >> > Nginx to proxy towards Tomcat.
> > > >> >
> > > >> >>>>
> > > >> >>>>> - No link on the tomcat root (http://management-server/ can
> > > >> >>>>> link internally to http://management-server/client , this
> > > >> >>>>> makes it easier for new users who don't know the URL for
> > > >> >>>>> the UI :)
> > > >> >>>>>
> > > >> >>>>>
> > > >> >>>> Sounds like a good idea to me, I always forget to add /client
> > > >> >>>> when I browse to new installations.
> > > >> >>>>
> > > >> >>
> > > >> >
> > > >> -----BEGIN PGP SIGNATURE-----
> > > >> Version: GnuPG v1
> > > >>
> > > >> iQIcBAEBAgAGBQJVUeEFAAoJEAGbWC3bPspCupwQAJjU6Akq18N9QcPYiOK60NR5
> > > >> P9+MF0UFvu1N5nHJxYwEHjIqwuzN9957xqx6LK0nhyDMN8ECadvZXweT5XhXbh+5
> > > >> G7D1Wqilav7GqGiye+4zV2CLRUI8KBPrUMFHwk4C4o1SqE6YxiX7E8/WY+cx2nt2
> > > >> LRAwPIvc3IL5QRIbiDfFm19mJRExBvHIZCYsMAPMgag2p85HOzuGxQ/NCcME7nna
> > > >> ODlHkjrPaWF66vZtyMA289R1e0Bab7hbElirCsA0VoTP3gbrwNriDf1KSfmOzIJD
> > > >> VyaSq2kcDIrWYWjuXxtjhIKdxCCkopgqRvjjiEDCQ3LVDaMsh4PSjhl2SuSU24l4
> > > >> mX6DZXjnt+3U01FOj9Bc76K28hawB3+7qqYPEsWlboi7Jz5hn0j04Kn9wRa+ZbfF
> > > >> 8t1DUpdPDtWd+HsyV/fdKXKY1X4Q/P3SatrqVZBymnyT/l/ENvqYLzLcNXHN9NSl
> > > >> 8o0+vhmTJRdbK9QoNeB8QtmtU+VB4iyC6x5tfwgqLvRNsSep3mpEgrKVa3h1Ssaz
> > > >> 14ChxYSNktOLJM3JuKBHqzSM0lxOHOT7wkiSXiXlCpbaoVRLcge7U4PjJW/GCSrE
> > > >> a/BAUYQzSKBAS/OpZHFizmQ0J7ASXaFDlBwy5XBfV+4nZjtClVR4oN9VHAJJ8d2X
> > > >> Fl89s3wdH0L/ag6Sd/oj
> > > >> =nbJY
> > > >> -----END PGP SIGNATURE-----
> > > >>
> > >
> >
>
Re: Cloudstack Repackaging / Distro support
Posted by Marcus <sh...@gmail.com>.
I don't think we are recommending a reverse proxy (are we?), it was just
brought up as a solution if someone wants port 80 to go to cloudstack. At
past jobs we put Apache on 80, and used it solely to host CS api docs for
the version of the API that the management server was running, as well as a
few other utilities that were management server specific.
Many shops also front CloudStack with a load balancer, in which case they
generally don't care what port it runs on.
I'm not sure it's worth changing 9090, either, but I think it's less of an
issue to do so. The best option is simply to make sure it is configurable,
so in the event someone wants to run two services they can adjust the port
(or use another IP). I don't know how many people care about or will run
cockpit, or any other service that will conflict on 8080, 9090, 8250 or any
other port we make up, and it seems like a losing battle to try to guess
that. In the end I guess I lean toward not inconveniencing our existing
user base by changing ports, to avoid a minor and fairly expected
inconvenience that a new setup might experience port conflicts with
unrelated services on common app ports.
On Tue, May 12, 2015 at 8:26 AM, Rafael Fonseca <rs...@gmail.com>
wrote:
> That is a good point David, but ideally, if we are recommending the use of
> a reverse proxy because our out of the box solution isn't good enough for
> production, i'd propose either:
>
> - Fix the performance problems with tomcat and make it production worthy
> (in what concerns the application server, i'd say its better to have this
> one locked down, to make sure user is using tested configs and lib versions
> and to NOT depend on distro provided scripts, install locations, libs, etc,
> since this is a basic requirement to get things going);
>
> AND/OR
>
> - Suggest that a reverse proxy is recommended and provide automatic
> configuration for the most common ones (like httpd and nginx) and not
> necessarily have them shipped with the product.
>
> I'm usually also against providing locked configs, but ideally, there
> should be some more automated sane defaults for a few things with OPTION to
> change.. instead of just having to to everything by yourself if we don't
> provide a default/automation .
>
> I'm keen with doing everything myself, but a lot of people aren't..
>
> I will also provide some fixes for performance soon, i've already
> identified a few ;)
>
> :)
>
> On Tue, May 12, 2015 at 4:37 PM, David Nalley <da...@gnsa.us> wrote:
>
> > On Tue, May 12, 2015 at 8:47 AM, Rafael Fonseca <rs...@gmail.com>
> > wrote:
> > > I'll stay away from touching port 80 for now, but isn't saving work to
> > the
> > > admin one of cloudstack's main goals?
> > >
> > > That is also the main reason to package this stuff and have rules for
> > > configuration :)
> > >
> > > I do see a lot of people complaining that cloudstack is hard to setup
> and
> > > has very long setup guides and a lot of stuff doesn't work on certain
> > > environments... i aim to put an end to that.. hopefully even the
> dumbest
> > > sysadmin will be able to get it up and running without much effort by
> the
> > > time i'm done :) . The effort reduction is also always valid for
> > > experienced sysadmins and developers ;)
> > >
> > >
> >
> > Sorta - we want to do enough sanely that people can get going, but not
> > so much that it locks people into specific configurations with no
> > option to change them. If an nginx shop suddenly found httpd deployed
> > because of using CloudStack, well, that would be a surprise. We don't
> > really want it to be a black box.
> >
> > >
> > >
> > > On Tue, May 12, 2015 at 1:16 PM, Wido den Hollander <wi...@widodh.nl>
> > wrote:
> > >
> > >> -----BEGIN PGP SIGNED MESSAGE-----
> > >> Hash: SHA1
> > >>
> > >>
> > >>
> > >> On 05/12/2015 12:03 PM, Rafael Fonseca wrote:
> > >> > Wido,
> > >> >
> > >> > If we were to recommend proxying with httpd, shouldn't cloudstack
> > >> > provide that as well out of the box?
> > >>
> > >> I'd stay away from that. Providing that out of the box means doing
> > >> more stuff which an admin should do.
> > >>
> > >> Wido
> > >>
> > >> > Btw, there isn't really a big performance gain by proxying through
> > >> > httpd nowadays, the new version of the packaging also includes
> > >> > using tomcat8, which has an improved http/nio connector, have a
> > >> > look here for some performance benchmarks :) ->
> > >> >
> > http://www.tomcatexpert.com/blog/2010/03/24/myth-or-truth-one-should-a
> > >> lways-use-apache-httpd-front-apache-tomcat-improve-perform
> > >> >
> > >> > What i think is that if we are going to suggest configuring httpd
> > >> > on the same box we should do it automatically, if not, tomcat can
> > >> > still run on port 80 by default and user can reverse proxy from any
> > >> > other machine :)
> > >> >
> > >> > Also, if we're sticking to tomcat, we should have scripts build
> > >> > the APR/native connector for improved performance :)
> > >> > http://tomcat.apache.org/native-doc/
> > >> >
> > >> > This would be an improvement independent from using or not
> > >> > httpd/nginx in front of tomcat.
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Tue, May 12, 2015 at 11:45 AM, Wido den Hollander
> > >> > <wi...@widodh.nl> wrote:
> > >> >
> > >> >
> > >> >
> > >> > On 05/12/2015 11:37 AM, Erik Weber wrote:
> > >> >>>> On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca
> > >> >>>> <rs...@gmail.com> wrote:
> > >> >>>>
> > >> >>>>> Hi all,
> > >> >>>>>
> > >> >>>>> I'm reworking the packaging system in cloudstack, and would
> > >> >>>>> like to gather your opinion on the following:
> > >> >>>>>
> > >> >>>>> - Fedora 2x runs systemd's cockpit on port 9090 by default
> > >> >>>>> This is a deal breaker for the cluster servlet port on this
> > >> >>>>> OS, the two possibilities would be to either pack changes
> > >> >>>>> to fedora's config on rpm install or simply change the
> > >> >>>>> servlet port to another one that does not clash on any
> > >> >>>>> distro.. any comments/suggestions?
> > >> >>>>>
> > >> >>>>> - Tomcat is not listening on port 80 Tomcat is using port
> > >> >>>>> 8080, which makes the user have to specify that in the
> > >> >>>>> browser.. should we change it? In ubuntu it's already
> > >> >>>>> running under jsvc, so it shouldn't be a problem.. same can
> > >> >>>>> be arranged for centos/other distros.
> > >> >>>>>
> > >> >>>>
> > >> >>>> Is it possible to ask the user for this during installation
> > >> >>>> and default to either 80 or 8080? I know Debian has a way to
> > >> >>>> interact with the user during install, not sure about
> > >> >>>> RedHat.
> > >> >>>>
> > >> >>>> I don't know the rationale behind putting it on port 8080 in
> > >> >>>> the first place, but personally I don't see a problem moving
> > >> >>>> it to port 80.
> > >> >>>>
> > >> >
> > >> > I'd say to stick to 8080 and recommend anybody to use Apache /
> > >> > Nginx to proxy towards Tomcat.
> > >> >
> > >> >>>>
> > >> >>>>> - No link on the tomcat root (http://management-server/ can
> > >> >>>>> link internally to http://management-server/client , this
> > >> >>>>> makes it easier for new users who don't know the URL for
> > >> >>>>> the UI :)
> > >> >>>>>
> > >> >>>>>
> > >> >>>> Sounds like a good idea to me, I always forget to add /client
> > >> >>>> when I browse to new installations.
> > >> >>>>
> > >> >>
> > >> >
> > >> -----BEGIN PGP SIGNATURE-----
> > >> Version: GnuPG v1
> > >>
> > >> iQIcBAEBAgAGBQJVUeEFAAoJEAGbWC3bPspCupwQAJjU6Akq18N9QcPYiOK60NR5
> > >> P9+MF0UFvu1N5nHJxYwEHjIqwuzN9957xqx6LK0nhyDMN8ECadvZXweT5XhXbh+5
> > >> G7D1Wqilav7GqGiye+4zV2CLRUI8KBPrUMFHwk4C4o1SqE6YxiX7E8/WY+cx2nt2
> > >> LRAwPIvc3IL5QRIbiDfFm19mJRExBvHIZCYsMAPMgag2p85HOzuGxQ/NCcME7nna
> > >> ODlHkjrPaWF66vZtyMA289R1e0Bab7hbElirCsA0VoTP3gbrwNriDf1KSfmOzIJD
> > >> VyaSq2kcDIrWYWjuXxtjhIKdxCCkopgqRvjjiEDCQ3LVDaMsh4PSjhl2SuSU24l4
> > >> mX6DZXjnt+3U01FOj9Bc76K28hawB3+7qqYPEsWlboi7Jz5hn0j04Kn9wRa+ZbfF
> > >> 8t1DUpdPDtWd+HsyV/fdKXKY1X4Q/P3SatrqVZBymnyT/l/ENvqYLzLcNXHN9NSl
> > >> 8o0+vhmTJRdbK9QoNeB8QtmtU+VB4iyC6x5tfwgqLvRNsSep3mpEgrKVa3h1Ssaz
> > >> 14ChxYSNktOLJM3JuKBHqzSM0lxOHOT7wkiSXiXlCpbaoVRLcge7U4PjJW/GCSrE
> > >> a/BAUYQzSKBAS/OpZHFizmQ0J7ASXaFDlBwy5XBfV+4nZjtClVR4oN9VHAJJ8d2X
> > >> Fl89s3wdH0L/ag6Sd/oj
> > >> =nbJY
> > >> -----END PGP SIGNATURE-----
> > >>
> >
>
Re: Cloudstack Repackaging / Distro support
Posted by Rafael Fonseca <rs...@gmail.com>.
That is a good point David, but ideally, if we are recommending the use of
a reverse proxy because our out of the box solution isn't good enough for
production, i'd propose either:
- Fix the performance problems with tomcat and make it production worthy
(in what concerns the application server, i'd say its better to have this
one locked down, to make sure user is using tested configs and lib versions
and to NOT depend on distro provided scripts, install locations, libs, etc,
since this is a basic requirement to get things going);
AND/OR
- Suggest that a reverse proxy is recommended and provide automatic
configuration for the most common ones (like httpd and nginx) and not
necessarily have them shipped with the product.
I'm usually also against providing locked configs, but ideally, there
should be some more automated sane defaults for a few things with OPTION to
change.. instead of just having to to everything by yourself if we don't
provide a default/automation .
I'm keen with doing everything myself, but a lot of people aren't..
I will also provide some fixes for performance soon, i've already
identified a few ;)
:)
On Tue, May 12, 2015 at 4:37 PM, David Nalley <da...@gnsa.us> wrote:
> On Tue, May 12, 2015 at 8:47 AM, Rafael Fonseca <rs...@gmail.com>
> wrote:
> > I'll stay away from touching port 80 for now, but isn't saving work to
> the
> > admin one of cloudstack's main goals?
> >
> > That is also the main reason to package this stuff and have rules for
> > configuration :)
> >
> > I do see a lot of people complaining that cloudstack is hard to setup and
> > has very long setup guides and a lot of stuff doesn't work on certain
> > environments... i aim to put an end to that.. hopefully even the dumbest
> > sysadmin will be able to get it up and running without much effort by the
> > time i'm done :) . The effort reduction is also always valid for
> > experienced sysadmins and developers ;)
> >
> >
>
> Sorta - we want to do enough sanely that people can get going, but not
> so much that it locks people into specific configurations with no
> option to change them. If an nginx shop suddenly found httpd deployed
> because of using CloudStack, well, that would be a surprise. We don't
> really want it to be a black box.
>
> >
> >
> > On Tue, May 12, 2015 at 1:16 PM, Wido den Hollander <wi...@widodh.nl>
> wrote:
> >
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >>
> >>
> >> On 05/12/2015 12:03 PM, Rafael Fonseca wrote:
> >> > Wido,
> >> >
> >> > If we were to recommend proxying with httpd, shouldn't cloudstack
> >> > provide that as well out of the box?
> >>
> >> I'd stay away from that. Providing that out of the box means doing
> >> more stuff which an admin should do.
> >>
> >> Wido
> >>
> >> > Btw, there isn't really a big performance gain by proxying through
> >> > httpd nowadays, the new version of the packaging also includes
> >> > using tomcat8, which has an improved http/nio connector, have a
> >> > look here for some performance benchmarks :) ->
> >> >
> http://www.tomcatexpert.com/blog/2010/03/24/myth-or-truth-one-should-a
> >> lways-use-apache-httpd-front-apache-tomcat-improve-perform
> >> >
> >> > What i think is that if we are going to suggest configuring httpd
> >> > on the same box we should do it automatically, if not, tomcat can
> >> > still run on port 80 by default and user can reverse proxy from any
> >> > other machine :)
> >> >
> >> > Also, if we're sticking to tomcat, we should have scripts build
> >> > the APR/native connector for improved performance :)
> >> > http://tomcat.apache.org/native-doc/
> >> >
> >> > This would be an improvement independent from using or not
> >> > httpd/nginx in front of tomcat.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On Tue, May 12, 2015 at 11:45 AM, Wido den Hollander
> >> > <wi...@widodh.nl> wrote:
> >> >
> >> >
> >> >
> >> > On 05/12/2015 11:37 AM, Erik Weber wrote:
> >> >>>> On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca
> >> >>>> <rs...@gmail.com> wrote:
> >> >>>>
> >> >>>>> Hi all,
> >> >>>>>
> >> >>>>> I'm reworking the packaging system in cloudstack, and would
> >> >>>>> like to gather your opinion on the following:
> >> >>>>>
> >> >>>>> - Fedora 2x runs systemd's cockpit on port 9090 by default
> >> >>>>> This is a deal breaker for the cluster servlet port on this
> >> >>>>> OS, the two possibilities would be to either pack changes
> >> >>>>> to fedora's config on rpm install or simply change the
> >> >>>>> servlet port to another one that does not clash on any
> >> >>>>> distro.. any comments/suggestions?
> >> >>>>>
> >> >>>>> - Tomcat is not listening on port 80 Tomcat is using port
> >> >>>>> 8080, which makes the user have to specify that in the
> >> >>>>> browser.. should we change it? In ubuntu it's already
> >> >>>>> running under jsvc, so it shouldn't be a problem.. same can
> >> >>>>> be arranged for centos/other distros.
> >> >>>>>
> >> >>>>
> >> >>>> Is it possible to ask the user for this during installation
> >> >>>> and default to either 80 or 8080? I know Debian has a way to
> >> >>>> interact with the user during install, not sure about
> >> >>>> RedHat.
> >> >>>>
> >> >>>> I don't know the rationale behind putting it on port 8080 in
> >> >>>> the first place, but personally I don't see a problem moving
> >> >>>> it to port 80.
> >> >>>>
> >> >
> >> > I'd say to stick to 8080 and recommend anybody to use Apache /
> >> > Nginx to proxy towards Tomcat.
> >> >
> >> >>>>
> >> >>>>> - No link on the tomcat root (http://management-server/ can
> >> >>>>> link internally to http://management-server/client , this
> >> >>>>> makes it easier for new users who don't know the URL for
> >> >>>>> the UI :)
> >> >>>>>
> >> >>>>>
> >> >>>> Sounds like a good idea to me, I always forget to add /client
> >> >>>> when I browse to new installations.
> >> >>>>
> >> >>
> >> >
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1
> >>
> >> iQIcBAEBAgAGBQJVUeEFAAoJEAGbWC3bPspCupwQAJjU6Akq18N9QcPYiOK60NR5
> >> P9+MF0UFvu1N5nHJxYwEHjIqwuzN9957xqx6LK0nhyDMN8ECadvZXweT5XhXbh+5
> >> G7D1Wqilav7GqGiye+4zV2CLRUI8KBPrUMFHwk4C4o1SqE6YxiX7E8/WY+cx2nt2
> >> LRAwPIvc3IL5QRIbiDfFm19mJRExBvHIZCYsMAPMgag2p85HOzuGxQ/NCcME7nna
> >> ODlHkjrPaWF66vZtyMA289R1e0Bab7hbElirCsA0VoTP3gbrwNriDf1KSfmOzIJD
> >> VyaSq2kcDIrWYWjuXxtjhIKdxCCkopgqRvjjiEDCQ3LVDaMsh4PSjhl2SuSU24l4
> >> mX6DZXjnt+3U01FOj9Bc76K28hawB3+7qqYPEsWlboi7Jz5hn0j04Kn9wRa+ZbfF
> >> 8t1DUpdPDtWd+HsyV/fdKXKY1X4Q/P3SatrqVZBymnyT/l/ENvqYLzLcNXHN9NSl
> >> 8o0+vhmTJRdbK9QoNeB8QtmtU+VB4iyC6x5tfwgqLvRNsSep3mpEgrKVa3h1Ssaz
> >> 14ChxYSNktOLJM3JuKBHqzSM0lxOHOT7wkiSXiXlCpbaoVRLcge7U4PjJW/GCSrE
> >> a/BAUYQzSKBAS/OpZHFizmQ0J7ASXaFDlBwy5XBfV+4nZjtClVR4oN9VHAJJ8d2X
> >> Fl89s3wdH0L/ag6Sd/oj
> >> =nbJY
> >> -----END PGP SIGNATURE-----
> >>
>
Re: Cloudstack Repackaging / Distro support
Posted by David Nalley <da...@gnsa.us>.
On Tue, May 12, 2015 at 8:47 AM, Rafael Fonseca <rs...@gmail.com> wrote:
> I'll stay away from touching port 80 for now, but isn't saving work to the
> admin one of cloudstack's main goals?
>
> That is also the main reason to package this stuff and have rules for
> configuration :)
>
> I do see a lot of people complaining that cloudstack is hard to setup and
> has very long setup guides and a lot of stuff doesn't work on certain
> environments... i aim to put an end to that.. hopefully even the dumbest
> sysadmin will be able to get it up and running without much effort by the
> time i'm done :) . The effort reduction is also always valid for
> experienced sysadmins and developers ;)
>
>
Sorta - we want to do enough sanely that people can get going, but not
so much that it locks people into specific configurations with no
option to change them. If an nginx shop suddenly found httpd deployed
because of using CloudStack, well, that would be a surprise. We don't
really want it to be a black box.
>
>
> On Tue, May 12, 2015 at 1:16 PM, Wido den Hollander <wi...@widodh.nl> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>> On 05/12/2015 12:03 PM, Rafael Fonseca wrote:
>> > Wido,
>> >
>> > If we were to recommend proxying with httpd, shouldn't cloudstack
>> > provide that as well out of the box?
>>
>> I'd stay away from that. Providing that out of the box means doing
>> more stuff which an admin should do.
>>
>> Wido
>>
>> > Btw, there isn't really a big performance gain by proxying through
>> > httpd nowadays, the new version of the packaging also includes
>> > using tomcat8, which has an improved http/nio connector, have a
>> > look here for some performance benchmarks :) ->
>> > http://www.tomcatexpert.com/blog/2010/03/24/myth-or-truth-one-should-a
>> lways-use-apache-httpd-front-apache-tomcat-improve-perform
>> >
>> > What i think is that if we are going to suggest configuring httpd
>> > on the same box we should do it automatically, if not, tomcat can
>> > still run on port 80 by default and user can reverse proxy from any
>> > other machine :)
>> >
>> > Also, if we're sticking to tomcat, we should have scripts build
>> > the APR/native connector for improved performance :)
>> > http://tomcat.apache.org/native-doc/
>> >
>> > This would be an improvement independent from using or not
>> > httpd/nginx in front of tomcat.
>> >
>> >
>> >
>> >
>> >
>> > On Tue, May 12, 2015 at 11:45 AM, Wido den Hollander
>> > <wi...@widodh.nl> wrote:
>> >
>> >
>> >
>> > On 05/12/2015 11:37 AM, Erik Weber wrote:
>> >>>> On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca
>> >>>> <rs...@gmail.com> wrote:
>> >>>>
>> >>>>> Hi all,
>> >>>>>
>> >>>>> I'm reworking the packaging system in cloudstack, and would
>> >>>>> like to gather your opinion on the following:
>> >>>>>
>> >>>>> - Fedora 2x runs systemd's cockpit on port 9090 by default
>> >>>>> This is a deal breaker for the cluster servlet port on this
>> >>>>> OS, the two possibilities would be to either pack changes
>> >>>>> to fedora's config on rpm install or simply change the
>> >>>>> servlet port to another one that does not clash on any
>> >>>>> distro.. any comments/suggestions?
>> >>>>>
>> >>>>> - Tomcat is not listening on port 80 Tomcat is using port
>> >>>>> 8080, which makes the user have to specify that in the
>> >>>>> browser.. should we change it? In ubuntu it's already
>> >>>>> running under jsvc, so it shouldn't be a problem.. same can
>> >>>>> be arranged for centos/other distros.
>> >>>>>
>> >>>>
>> >>>> Is it possible to ask the user for this during installation
>> >>>> and default to either 80 or 8080? I know Debian has a way to
>> >>>> interact with the user during install, not sure about
>> >>>> RedHat.
>> >>>>
>> >>>> I don't know the rationale behind putting it on port 8080 in
>> >>>> the first place, but personally I don't see a problem moving
>> >>>> it to port 80.
>> >>>>
>> >
>> > I'd say to stick to 8080 and recommend anybody to use Apache /
>> > Nginx to proxy towards Tomcat.
>> >
>> >>>>
>> >>>>> - No link on the tomcat root (http://management-server/ can
>> >>>>> link internally to http://management-server/client , this
>> >>>>> makes it easier for new users who don't know the URL for
>> >>>>> the UI :)
>> >>>>>
>> >>>>>
>> >>>> Sounds like a good idea to me, I always forget to add /client
>> >>>> when I browse to new installations.
>> >>>>
>> >>
>> >
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>>
>> iQIcBAEBAgAGBQJVUeEFAAoJEAGbWC3bPspCupwQAJjU6Akq18N9QcPYiOK60NR5
>> P9+MF0UFvu1N5nHJxYwEHjIqwuzN9957xqx6LK0nhyDMN8ECadvZXweT5XhXbh+5
>> G7D1Wqilav7GqGiye+4zV2CLRUI8KBPrUMFHwk4C4o1SqE6YxiX7E8/WY+cx2nt2
>> LRAwPIvc3IL5QRIbiDfFm19mJRExBvHIZCYsMAPMgag2p85HOzuGxQ/NCcME7nna
>> ODlHkjrPaWF66vZtyMA289R1e0Bab7hbElirCsA0VoTP3gbrwNriDf1KSfmOzIJD
>> VyaSq2kcDIrWYWjuXxtjhIKdxCCkopgqRvjjiEDCQ3LVDaMsh4PSjhl2SuSU24l4
>> mX6DZXjnt+3U01FOj9Bc76K28hawB3+7qqYPEsWlboi7Jz5hn0j04Kn9wRa+ZbfF
>> 8t1DUpdPDtWd+HsyV/fdKXKY1X4Q/P3SatrqVZBymnyT/l/ENvqYLzLcNXHN9NSl
>> 8o0+vhmTJRdbK9QoNeB8QtmtU+VB4iyC6x5tfwgqLvRNsSep3mpEgrKVa3h1Ssaz
>> 14ChxYSNktOLJM3JuKBHqzSM0lxOHOT7wkiSXiXlCpbaoVRLcge7U4PjJW/GCSrE
>> a/BAUYQzSKBAS/OpZHFizmQ0J7ASXaFDlBwy5XBfV+4nZjtClVR4oN9VHAJJ8d2X
>> Fl89s3wdH0L/ag6Sd/oj
>> =nbJY
>> -----END PGP SIGNATURE-----
>>
Re: Cloudstack Repackaging / Distro support
Posted by Rafael Fonseca <rs...@gmail.com>.
I'll stay away from touching port 80 for now, but isn't saving work to the
admin one of cloudstack's main goals?
That is also the main reason to package this stuff and have rules for
configuration :)
I do see a lot of people complaining that cloudstack is hard to setup and
has very long setup guides and a lot of stuff doesn't work on certain
environments... i aim to put an end to that.. hopefully even the dumbest
sysadmin will be able to get it up and running without much effort by the
time i'm done :) . The effort reduction is also always valid for
experienced sysadmins and developers ;)
On Tue, May 12, 2015 at 1:16 PM, Wido den Hollander <wi...@widodh.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> On 05/12/2015 12:03 PM, Rafael Fonseca wrote:
> > Wido,
> >
> > If we were to recommend proxying with httpd, shouldn't cloudstack
> > provide that as well out of the box?
>
> I'd stay away from that. Providing that out of the box means doing
> more stuff which an admin should do.
>
> Wido
>
> > Btw, there isn't really a big performance gain by proxying through
> > httpd nowadays, the new version of the packaging also includes
> > using tomcat8, which has an improved http/nio connector, have a
> > look here for some performance benchmarks :) ->
> > http://www.tomcatexpert.com/blog/2010/03/24/myth-or-truth-one-should-a
> lways-use-apache-httpd-front-apache-tomcat-improve-perform
> >
> > What i think is that if we are going to suggest configuring httpd
> > on the same box we should do it automatically, if not, tomcat can
> > still run on port 80 by default and user can reverse proxy from any
> > other machine :)
> >
> > Also, if we're sticking to tomcat, we should have scripts build
> > the APR/native connector for improved performance :)
> > http://tomcat.apache.org/native-doc/
> >
> > This would be an improvement independent from using or not
> > httpd/nginx in front of tomcat.
> >
> >
> >
> >
> >
> > On Tue, May 12, 2015 at 11:45 AM, Wido den Hollander
> > <wi...@widodh.nl> wrote:
> >
> >
> >
> > On 05/12/2015 11:37 AM, Erik Weber wrote:
> >>>> On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca
> >>>> <rs...@gmail.com> wrote:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> I'm reworking the packaging system in cloudstack, and would
> >>>>> like to gather your opinion on the following:
> >>>>>
> >>>>> - Fedora 2x runs systemd's cockpit on port 9090 by default
> >>>>> This is a deal breaker for the cluster servlet port on this
> >>>>> OS, the two possibilities would be to either pack changes
> >>>>> to fedora's config on rpm install or simply change the
> >>>>> servlet port to another one that does not clash on any
> >>>>> distro.. any comments/suggestions?
> >>>>>
> >>>>> - Tomcat is not listening on port 80 Tomcat is using port
> >>>>> 8080, which makes the user have to specify that in the
> >>>>> browser.. should we change it? In ubuntu it's already
> >>>>> running under jsvc, so it shouldn't be a problem.. same can
> >>>>> be arranged for centos/other distros.
> >>>>>
> >>>>
> >>>> Is it possible to ask the user for this during installation
> >>>> and default to either 80 or 8080? I know Debian has a way to
> >>>> interact with the user during install, not sure about
> >>>> RedHat.
> >>>>
> >>>> I don't know the rationale behind putting it on port 8080 in
> >>>> the first place, but personally I don't see a problem moving
> >>>> it to port 80.
> >>>>
> >
> > I'd say to stick to 8080 and recommend anybody to use Apache /
> > Nginx to proxy towards Tomcat.
> >
> >>>>
> >>>>> - No link on the tomcat root (http://management-server/ can
> >>>>> link internally to http://management-server/client , this
> >>>>> makes it easier for new users who don't know the URL for
> >>>>> the UI :)
> >>>>>
> >>>>>
> >>>> Sounds like a good idea to me, I always forget to add /client
> >>>> when I browse to new installations.
> >>>>
> >>
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJVUeEFAAoJEAGbWC3bPspCupwQAJjU6Akq18N9QcPYiOK60NR5
> P9+MF0UFvu1N5nHJxYwEHjIqwuzN9957xqx6LK0nhyDMN8ECadvZXweT5XhXbh+5
> G7D1Wqilav7GqGiye+4zV2CLRUI8KBPrUMFHwk4C4o1SqE6YxiX7E8/WY+cx2nt2
> LRAwPIvc3IL5QRIbiDfFm19mJRExBvHIZCYsMAPMgag2p85HOzuGxQ/NCcME7nna
> ODlHkjrPaWF66vZtyMA289R1e0Bab7hbElirCsA0VoTP3gbrwNriDf1KSfmOzIJD
> VyaSq2kcDIrWYWjuXxtjhIKdxCCkopgqRvjjiEDCQ3LVDaMsh4PSjhl2SuSU24l4
> mX6DZXjnt+3U01FOj9Bc76K28hawB3+7qqYPEsWlboi7Jz5hn0j04Kn9wRa+ZbfF
> 8t1DUpdPDtWd+HsyV/fdKXKY1X4Q/P3SatrqVZBymnyT/l/ENvqYLzLcNXHN9NSl
> 8o0+vhmTJRdbK9QoNeB8QtmtU+VB4iyC6x5tfwgqLvRNsSep3mpEgrKVa3h1Ssaz
> 14ChxYSNktOLJM3JuKBHqzSM0lxOHOT7wkiSXiXlCpbaoVRLcge7U4PjJW/GCSrE
> a/BAUYQzSKBAS/OpZHFizmQ0J7ASXaFDlBwy5XBfV+4nZjtClVR4oN9VHAJJ8d2X
> Fl89s3wdH0L/ag6Sd/oj
> =nbJY
> -----END PGP SIGNATURE-----
>
Re: Cloudstack Repackaging / Distro support
Posted by Wido den Hollander <wi...@widodh.nl>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/12/2015 12:03 PM, Rafael Fonseca wrote:
> Wido,
>
> If we were to recommend proxying with httpd, shouldn't cloudstack
> provide that as well out of the box?
I'd stay away from that. Providing that out of the box means doing
more stuff which an admin should do.
Wido
> Btw, there isn't really a big performance gain by proxying through
> httpd nowadays, the new version of the packaging also includes
> using tomcat8, which has an improved http/nio connector, have a
> look here for some performance benchmarks :) ->
> http://www.tomcatexpert.com/blog/2010/03/24/myth-or-truth-one-should-a
lways-use-apache-httpd-front-apache-tomcat-improve-perform
>
> What i think is that if we are going to suggest configuring httpd
> on the same box we should do it automatically, if not, tomcat can
> still run on port 80 by default and user can reverse proxy from any
> other machine :)
>
> Also, if we're sticking to tomcat, we should have scripts build
> the APR/native connector for improved performance :)
> http://tomcat.apache.org/native-doc/
>
> This would be an improvement independent from using or not
> httpd/nginx in front of tomcat.
>
>
>
>
>
> On Tue, May 12, 2015 at 11:45 AM, Wido den Hollander
> <wi...@widodh.nl> wrote:
>
>
>
> On 05/12/2015 11:37 AM, Erik Weber wrote:
>>>> On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca
>>>> <rs...@gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm reworking the packaging system in cloudstack, and would
>>>>> like to gather your opinion on the following:
>>>>>
>>>>> - Fedora 2x runs systemd's cockpit on port 9090 by default
>>>>> This is a deal breaker for the cluster servlet port on this
>>>>> OS, the two possibilities would be to either pack changes
>>>>> to fedora's config on rpm install or simply change the
>>>>> servlet port to another one that does not clash on any
>>>>> distro.. any comments/suggestions?
>>>>>
>>>>> - Tomcat is not listening on port 80 Tomcat is using port
>>>>> 8080, which makes the user have to specify that in the
>>>>> browser.. should we change it? In ubuntu it's already
>>>>> running under jsvc, so it shouldn't be a problem.. same can
>>>>> be arranged for centos/other distros.
>>>>>
>>>>
>>>> Is it possible to ask the user for this during installation
>>>> and default to either 80 or 8080? I know Debian has a way to
>>>> interact with the user during install, not sure about
>>>> RedHat.
>>>>
>>>> I don't know the rationale behind putting it on port 8080 in
>>>> the first place, but personally I don't see a problem moving
>>>> it to port 80.
>>>>
>
> I'd say to stick to 8080 and recommend anybody to use Apache /
> Nginx to proxy towards Tomcat.
>
>>>>
>>>>> - No link on the tomcat root (http://management-server/ can
>>>>> link internally to http://management-server/client , this
>>>>> makes it easier for new users who don't know the URL for
>>>>> the UI :)
>>>>>
>>>>>
>>>> Sounds like a good idea to me, I always forget to add /client
>>>> when I browse to new installations.
>>>>
>>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJVUeEFAAoJEAGbWC3bPspCupwQAJjU6Akq18N9QcPYiOK60NR5
P9+MF0UFvu1N5nHJxYwEHjIqwuzN9957xqx6LK0nhyDMN8ECadvZXweT5XhXbh+5
G7D1Wqilav7GqGiye+4zV2CLRUI8KBPrUMFHwk4C4o1SqE6YxiX7E8/WY+cx2nt2
LRAwPIvc3IL5QRIbiDfFm19mJRExBvHIZCYsMAPMgag2p85HOzuGxQ/NCcME7nna
ODlHkjrPaWF66vZtyMA289R1e0Bab7hbElirCsA0VoTP3gbrwNriDf1KSfmOzIJD
VyaSq2kcDIrWYWjuXxtjhIKdxCCkopgqRvjjiEDCQ3LVDaMsh4PSjhl2SuSU24l4
mX6DZXjnt+3U01FOj9Bc76K28hawB3+7qqYPEsWlboi7Jz5hn0j04Kn9wRa+ZbfF
8t1DUpdPDtWd+HsyV/fdKXKY1X4Q/P3SatrqVZBymnyT/l/ENvqYLzLcNXHN9NSl
8o0+vhmTJRdbK9QoNeB8QtmtU+VB4iyC6x5tfwgqLvRNsSep3mpEgrKVa3h1Ssaz
14ChxYSNktOLJM3JuKBHqzSM0lxOHOT7wkiSXiXlCpbaoVRLcge7U4PjJW/GCSrE
a/BAUYQzSKBAS/OpZHFizmQ0J7ASXaFDlBwy5XBfV+4nZjtClVR4oN9VHAJJ8d2X
Fl89s3wdH0L/ag6Sd/oj
=nbJY
-----END PGP SIGNATURE-----
Re: Cloudstack Repackaging / Distro support
Posted by Rafael Fonseca <rs...@gmail.com>.
Wido,
If we were to recommend proxying with httpd, shouldn't cloudstack provide
that as well out of the box?
Btw, there isn't really a big performance gain by proxying through httpd
nowadays, the new version of the packaging also includes using tomcat8,
which has an improved http/nio connector, have a look here for some
performance benchmarks :) ->
http://www.tomcatexpert.com/blog/2010/03/24/myth-or-truth-one-should-always-use-apache-httpd-front-apache-tomcat-improve-perform
What i think is that if we are going to suggest configuring httpd on the
same box we should do it automatically, if not, tomcat can still run on
port 80 by default and user can reverse proxy from any other machine :)
Also, if we're sticking to tomcat, we should have scripts build the
APR/native connector for improved performance :)
http://tomcat.apache.org/native-doc/
This would be an improvement independent from using or not httpd/nginx in
front of tomcat.
On Tue, May 12, 2015 at 11:45 AM, Wido den Hollander <wi...@widodh.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> On 05/12/2015 11:37 AM, Erik Weber wrote:
> > On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca
> > <rs...@gmail.com> wrote:
> >
> >> Hi all,
> >>
> >> I'm reworking the packaging system in cloudstack, and would like
> >> to gather your opinion on the following:
> >>
> >> - Fedora 2x runs systemd's cockpit on port 9090 by default This
> >> is a deal breaker for the cluster servlet port on this OS, the
> >> two possibilities would be to either pack changes to fedora's
> >> config on rpm install or simply change the servlet port to
> >> another one that does not clash on any distro.. any
> >> comments/suggestions?
> >>
> >> - Tomcat is not listening on port 80 Tomcat is using port 8080,
> >> which makes the user have to specify that in the browser.. should
> >> we change it? In ubuntu it's already running under jsvc, so it
> >> shouldn't be a problem.. same can be arranged for centos/other
> >> distros.
> >>
> >
> > Is it possible to ask the user for this during installation and
> > default to either 80 or 8080? I know Debian has a way to interact
> > with the user during install, not sure about RedHat.
> >
> > I don't know the rationale behind putting it on port 8080 in the
> > first place, but personally I don't see a problem moving it to port
> > 80.
> >
>
> I'd say to stick to 8080 and recommend anybody to use Apache / Nginx
> to proxy towards Tomcat.
>
> >
> >> - No link on the tomcat root (http://management-server/ can link
> >> internally to http://management-server/client , this makes it
> >> easier for new users who don't know the URL for the UI :)
> >>
> >>
> > Sounds like a good idea to me, I always forget to add /client when
> > I browse to new installations.
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJVUcugAAoJEAGbWC3bPspCmzYP+QF8FOnikqiqUI+qtsHB70gf
> Z3RbTltbncGb4ENg48kDxrXThufE2lHCOOZYkwb3mrsqX78BdWojlxxvymbp3SO8
> HdysI7LcGDGnoKPdveGtrHqtGBWhbcgIT5f43bU1Ks7GaQVjWdMdayp6ooYEtjA4
> CpzzlqAJvA0oibfeTLFnfSF0IiSvqXtminjjWcNzhifusfn2aijzowemNFyYOU4d
> UxDVdaKGUSwMxKGj3Zvqva1KO3tng5nKpS8r6Xe7WyVCKAJ8ewaNUI6KJ5hOw50J
> ENLrdcRZ82Nw+iqtV8MgB0VJSXKuWYJ+OQ6f9SplmJOe3Au+jyfIFEqwliGCtEmL
> 01naERq+/7HAz1JjSoj0c+LBNBxB6FePpZDgkhJJZ51NoLeE/yQuxShV8Ihnk/39
> yIfDyb/95DMG+n9qdglp7hav+tCwJL6q70LIK1DUXRleLvPyrgqnvx9AZwQtoYcZ
> BuTn9F6xiZg8Q5xRQokUiyNzj6RWlm8EZF8PBf/og6DfVYuH559mPqu3OJcAlJkz
> /RB3vhNjc/3Hso2lVFu2p6cVvc+hkM31c4/h338d6NPEqD3wMkBdhCDvTf+jkC7i
> GNfYLtKlc7KIkA5bCJxvxbidIxdi1adXs6Lxz8xY0mKliMORd9NyLca6KIXOqAkJ
> j6c/I3UglqkTLQjOKjXZ
> =pBnh
> -----END PGP SIGNATURE-----
>
Re: Cloudstack Repackaging / Distro support
Posted by Wido den Hollander <wi...@widodh.nl>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/12/2015 11:37 AM, Erik Weber wrote:
> On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca
> <rs...@gmail.com> wrote:
>
>> Hi all,
>>
>> I'm reworking the packaging system in cloudstack, and would like
>> to gather your opinion on the following:
>>
>> - Fedora 2x runs systemd's cockpit on port 9090 by default This
>> is a deal breaker for the cluster servlet port on this OS, the
>> two possibilities would be to either pack changes to fedora's
>> config on rpm install or simply change the servlet port to
>> another one that does not clash on any distro.. any
>> comments/suggestions?
>>
>> - Tomcat is not listening on port 80 Tomcat is using port 8080,
>> which makes the user have to specify that in the browser.. should
>> we change it? In ubuntu it's already running under jsvc, so it
>> shouldn't be a problem.. same can be arranged for centos/other
>> distros.
>>
>
> Is it possible to ask the user for this during installation and
> default to either 80 or 8080? I know Debian has a way to interact
> with the user during install, not sure about RedHat.
>
> I don't know the rationale behind putting it on port 8080 in the
> first place, but personally I don't see a problem moving it to port
> 80.
>
I'd say to stick to 8080 and recommend anybody to use Apache / Nginx
to proxy towards Tomcat.
>
>> - No link on the tomcat root (http://management-server/ can link
>> internally to http://management-server/client , this makes it
>> easier for new users who don't know the URL for the UI :)
>>
>>
> Sounds like a good idea to me, I always forget to add /client when
> I browse to new installations.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJVUcugAAoJEAGbWC3bPspCmzYP+QF8FOnikqiqUI+qtsHB70gf
Z3RbTltbncGb4ENg48kDxrXThufE2lHCOOZYkwb3mrsqX78BdWojlxxvymbp3SO8
HdysI7LcGDGnoKPdveGtrHqtGBWhbcgIT5f43bU1Ks7GaQVjWdMdayp6ooYEtjA4
CpzzlqAJvA0oibfeTLFnfSF0IiSvqXtminjjWcNzhifusfn2aijzowemNFyYOU4d
UxDVdaKGUSwMxKGj3Zvqva1KO3tng5nKpS8r6Xe7WyVCKAJ8ewaNUI6KJ5hOw50J
ENLrdcRZ82Nw+iqtV8MgB0VJSXKuWYJ+OQ6f9SplmJOe3Au+jyfIFEqwliGCtEmL
01naERq+/7HAz1JjSoj0c+LBNBxB6FePpZDgkhJJZ51NoLeE/yQuxShV8Ihnk/39
yIfDyb/95DMG+n9qdglp7hav+tCwJL6q70LIK1DUXRleLvPyrgqnvx9AZwQtoYcZ
BuTn9F6xiZg8Q5xRQokUiyNzj6RWlm8EZF8PBf/og6DfVYuH559mPqu3OJcAlJkz
/RB3vhNjc/3Hso2lVFu2p6cVvc+hkM31c4/h338d6NPEqD3wMkBdhCDvTf+jkC7i
GNfYLtKlc7KIkA5bCJxvxbidIxdi1adXs6Lxz8xY0mKliMORd9NyLca6KIXOqAkJ
j6c/I3UglqkTLQjOKjXZ
=pBnh
-----END PGP SIGNATURE-----
Re: Cloudstack Repackaging / Distro support
Posted by Erik Weber <te...@gmail.com>.
On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca <rs...@gmail.com>
wrote:
> Hi all,
>
> I'm reworking the packaging system in cloudstack, and would like to gather
> your opinion on the following:
>
> - Fedora 2x runs systemd's cockpit on port 9090 by default
> This is a deal breaker for the cluster servlet port on this OS, the two
> possibilities would be to either pack changes to fedora's config on rpm
> install or simply change the servlet port to another one that does not
> clash on any distro.. any comments/suggestions?
>
> - Tomcat is not listening on port 80
> Tomcat is using port 8080, which makes the user have to specify that in
> the browser.. should we change it? In ubuntu it's already running under
> jsvc, so it shouldn't be a problem.. same can be arranged for centos/other
> distros.
>
Is it possible to ask the user for this during installation and default to
either 80 or 8080? I know Debian has a way to interact with the user during
install, not sure about RedHat.
I don't know the rationale behind putting it on port 8080 in the first
place, but personally I don't see a problem moving it to port 80.
> - No link on the tomcat root (http://management-server/ can link
> internally
> to http://management-server/client , this makes it easier for new users
> who
> don't know the URL for the UI :)
>
>
Sounds like a good idea to me, I always forget to add /client when I browse
to new installations.
--
Erik
Re: Cloudstack Repackaging / Distro support
Posted by Rafael Fonseca <rs...@gmail.com>.
Hi Lazlo,
I hadn't seen that JIRA issue yet :)
I am indeed working in packaging and have taken a different approach, which
provides for much cleaner distro support.
I'm currently finishing up on having the exact same installer working for
both centos7 and fedora2x without any need for special customization.
It's working well with both java 7 and 8, build test and runtime as far as
I can see :)
I'll be committing the fedora part later on
https://github.com/apache/cloudstack/pull/238 this :)
Perhaps you could help test if everything is ok?
About the reverse proxy, it might have numerous reasons :)
The most popular reason for putting tomcat behind an httpd is because of
historic bad performance in tomcat for serving static files and such, this
would allow for caching on a faster engine :)
There's also a reason of security, which might lead some folks into having
specific machines designed to secure http traffic between zones or
something of the sorts.
On Tue, May 12, 2015 at 6:42 PM, Laszlo Hornyak <la...@gmail.com>
wrote:
> Hi Rafael,
>
> There is a ticket for fedora packaging: CLOUDSTACK-8163 I have sent patches
> with that issue ID. There are quite a lot of things to do...
> Are you working on the management server packaging?
> Why does the management service have to start as a separate service? It
> could be just a webapp under tomcat.
>
> Basically what are the advantages of having a reverse proxy in front of
> tomcat? Is httpd/nginx more secure than tomcat?
>
> Best regards,
> Laszlo
>
> On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca <rs...@gmail.com>
> wrote:
>
> > Hi all,
> >
> > I'm reworking the packaging system in cloudstack, and would like to
> gather
> > your opinion on the following:
> >
> > - Fedora 2x runs systemd's cockpit on port 9090 by default
> > This is a deal breaker for the cluster servlet port on this OS, the two
> > possibilities would be to either pack changes to fedora's config on rpm
> > install or simply change the servlet port to another one that does not
> > clash on any distro.. any comments/suggestions?
> >
> > - Tomcat is not listening on port 80
> > Tomcat is using port 8080, which makes the user have to specify that
> in
> > the browser.. should we change it? In ubuntu it's already running under
> > jsvc, so it shouldn't be a problem.. same can be arranged for
> centos/other
> > distros.
> >
> > - No link on the tomcat root (http://management-server/ can link
> > internally
> > to http://management-server/client , this makes it easier for new users
> > who
> > don't know the URL for the UI :)
> >
> > Thanks for your input :)
> >
>
>
>
> --
>
> EOF
>
Re: Cloudstack Repackaging / Distro support
Posted by Laszlo Hornyak <la...@gmail.com>.
Hi Rafael,
There is a ticket for fedora packaging: CLOUDSTACK-8163 I have sent patches
with that issue ID. There are quite a lot of things to do...
Are you working on the management server packaging?
Why does the management service have to start as a separate service? It
could be just a webapp under tomcat.
Basically what are the advantages of having a reverse proxy in front of
tomcat? Is httpd/nginx more secure than tomcat?
Best regards,
Laszlo
On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca <rs...@gmail.com>
wrote:
> Hi all,
>
> I'm reworking the packaging system in cloudstack, and would like to gather
> your opinion on the following:
>
> - Fedora 2x runs systemd's cockpit on port 9090 by default
> This is a deal breaker for the cluster servlet port on this OS, the two
> possibilities would be to either pack changes to fedora's config on rpm
> install or simply change the servlet port to another one that does not
> clash on any distro.. any comments/suggestions?
>
> - Tomcat is not listening on port 80
> Tomcat is using port 8080, which makes the user have to specify that in
> the browser.. should we change it? In ubuntu it's already running under
> jsvc, so it shouldn't be a problem.. same can be arranged for centos/other
> distros.
>
> - No link on the tomcat root (http://management-server/ can link
> internally
> to http://management-server/client , this makes it easier for new users
> who
> don't know the URL for the UI :)
>
> Thanks for your input :)
>
--
EOF