cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos ReƔtegui <create...@gmail.com>
Subject Re: Cloudstack Repackaging / Distro support
Date Tue, 12 May 2015 21:15:44 GMT
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 <rsafonseca@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 <mailto: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 <mailto: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 <mailto:rsafonseca@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
<mailto: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 <mailto: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 <mailto: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
<mailto:david@gnsa.us>>
>> wrote:
>>>>>>> 
>>>>>>>> On Tue, May 12, 2015 at 8:47 AM, Rafael Fonseca <
>>>>>> rsafonseca@gmail.com <mailto: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