cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Fonseca <rsafons...@gmail.com>
Subject Re: Cloudstack Repackaging / Distro support
Date Tue, 12 May 2015 17:20:46 GMT
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> 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 <david@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
> > > >> > <wido@widodh.nl> wrote:
> > > >> >
> > > >> >
> > > >> >
> > > >> > On 05/12/2015 11:37 AM, Erik Weber wrote:
> > > >> >>>> On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca
> > > >> >>>> <rsafonseca@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-----
> > > >>
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message