cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <da...@gnsa.us>
Subject Re: [DISCUSS] fixing the tomcat situation, post 4.1?
Date Mon, 04 Mar 2013 05:03:16 GMT
On Sun, Mar 3, 2013 at 8:04 AM, Noa Resare <noa@spotify.com> wrote:
> So, when working with the 4.1 packaging issues I have more than once been
> intensely frustrated with the current tomcat situation.
>
> To recap: Some cloustack components are set up as web applications and
> requires a servlet container as their execution environment. The current
> solution to provide such as servlet container is to have the cloudstack
> package depend on an Apache Tomcat 6 package provided by the OS
> distribution. Cloudstack then ships copies of the configuration files
> needed by tomcat to run along with init scripts that bootstraps tomcat in a
> way that references the cloudstack shipped artifacts. This setup has many
> problems.
>
> # Cloudstack assumes that it's configuration files will be enough in sync
> with what the externally provided tomcat expects.
>
> # Lots and lots of fairly esoteric config files included in cloudstack
> makes the learning curve steep
>
> # Tomcat setup, as it stands without trying any specific hackery to make it
> do other stuff, is a labyrinth of shell scripts
>
> # Things gets even more complicated when cloudstack invokes tomcat provided
> scripts.
>
> # tomcat has it's own log files for the early parts of it's startup.
>
> It shouldn't need to be this hard. webapps are standardized for a reason,
> and the requirements we have on a servlet execution environments are not
> that special (one webapp on /client listening one port, and possibly
> another webapp for the aws stuff listening on another port)
>
> As a proof of concept I hacked together the starting points of
> a replacement for this whole mess yesterday, a few tens of lines of code
> setting up an embedded jetty web container. A few lines of code to parse a
> config file, set up logging and spawn an embedded servlet container.
>
> Points of discussion:
>
> # What features do we need for our servlet container? Do I miss
> anything obvious?
>
> # Do we have some kind of loyalty towards tomcat, it being one of the main
> apache projects after all? 2 minutes of googling seems to indicate that
> there are embedded tomcat options as well, but I know jetty better so that
> seemed like a better stating point for my proof of concept.
>
> My proof of concept code is available here:
> https://github.com/noaresare/incubator-cloudstack/tree/noa/runner
>
> /noa
>
>

I don't think that we have any loyalties to Tomcat.

You aren't the first person to voice frustration at how things are deployed.
I'd be happy if we ended up with a truly deployable war.

Thanks for starting this work.

--David

Mime
View raw message