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 <shadow...@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 <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----- > > > >> > > > > > >
