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 21:09:20 GMT
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> 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>
> 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>
> > 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 <rsafonseca@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> 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