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 <rsafons...@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 <rsafons...@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 <w...@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 > > >> > <w...@widodh.nl> wrote: > > >> > > > >> > > > >> > > > >> > On 05/12/2015 11:37 AM, Erik Weber wrote: > > >> >>>> On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca > > >> >>>> <rsafons...@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----- > > >> > > >
