Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Date: Thu, 10 Aug 2017 17:23:59 +0200 (CEST)
From: Wido den Hollander <wido@widodh.nl>
To: Rohit Yadav <rohit.yadav@shapeblue.com>, dev@cloudstack.apache.org
Cc: users@cloudstack.apache.org
Message-ID: <735563560.246.1502378639567@ox.pcextreme.nl>
In-Reply-To: <VI1PR0701MB294464B06D8B554399A246F5E9880@VI1PR0701MB2944.eurprd07.prod.outlook.com>
References: <VI1PR0701MB294464B06D8B554399A246F5E9880@VI1PR0701MB2944.eurprd07.prod.outlook.com>
Subject: Re: [DISCUSS] Moving to embedded Jetty and fatjar CloudStack
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Medium
archived-at: Thu, 10 Aug 2017 15:24:18 -0000


> Op 10 augustus 2017 om 14:09 schreef Rohit Yadav <rohit.yadav@shapeblue.c=
om>:
>=20
>=20
> All,
>=20
>=20
> Distro provided tomcat6/7/* has caused production issues for few users in=
 the past. Due to this, the ACS deployments are inconsistent with the versi=
on/jars of tomcat in use. By allowing exploded war to be shipped, can allow=
 admins to sometimes overwrite cloudstack jars causing production issues. I=
 think moving to a CloudStack uber/fat jar will make it easier to deploy Cl=
oudStack in environments and write custom init/systemd scripts and fix clou=
dstack setup databases/management scripts without assuming the distro we're=
 on.
>=20

Yes, I agree. A flat jar makes things a lot easier.

>=20
> With this discussion thread, I would like to engage with the community if=
 they've any reservations from moving away from tomcat to embedded jetty + =
fat/uber jar based packaging. Please share your thoughts and comments.
>=20
>=20
> On very high level the packaging will provide the following:
>=20
> - A ServerDaemon class that can accept custom location of UI (webapp dire=
ctory), logging, and other environment options, part of the fatjar.
>=20
> - A config file (xml/yml or otherwise) where you can configure keystore/S=
SL-certificates, paths (/client), ports, logging etc.
>=20
> - Default libraries/plugin path at /usr/share/cloudstack-management/lib, =
UI path at /usr/share/cloudstack-management/webapp
>=20
> - A default file (available at /etc/default/cloudstack-management or syml=
ink at /etc/sysconfig etc) where you can specific custom variables, java op=
tions, classpath etc.
>=20
> - Refactored init.d/systemd scripts to be commonly used b/w rpm/deb build=
 scripts
>=20
> - A new/improve logrotate file
>=20
> - Logging will be handled by log4j (the same xml/config file you normally=
 use)
>=20
> - Currently we're using jsvc to handle mgmt server process, however we ma=
y move to java+systemd completely
>=20

I suggest that we only use init.d on RHEL 6 and Ubuntu 14.04, but on RHEL 7=
 and Ubuntu 16.04 (any distro that runs with systemd) we should try to avoi=
d using jsvc.

That way we don't have to daemonize the MGMT server and keep it attached to=
 systemd. Also makes it easy to just print logs to stdout and have journalc=
tl take care of them.

>=20
> Marc-Aur=C3=A8le (ExoScale) and I have collaborated on this problem and w=
e finally have a PR (not complete) where we can show this actually works, p=
lease have a look:

Awesome work!

>=20
> https://github.com/apache/cloudstack/pull/2226
>=20
>=20
> Once the PR is accepted, we can include a topic page in the 4.11/future r=
elease notes docs about upgrading in-place and setting up ssl certs etc.
>=20
>=20
> Regards.
>=20
> rohit.yadav@shapeblue.com=20
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>  =20
> =20
>