Co-bundling Jetty ?

[Rod Widdowson]

> It would be good to have a discussion on a Friday call, but I wanted
> to bring it up here first.

I didn't see any notes on the discussion from last Friday so I hope I am not
too late to throw in my two cents here.

The cost I worry about the most is the cost of having to track security and
other mandatory updates to Jetty.  This means we have to be experts on it
ourselves and have to watch it closely, with the added risk that we end up
having to do coding level support for it because no one else can or will
(are we not already doing this for other projects?)

The next risk is that it is a decision that we cannot easily un-take.  It
would be difficult to say "Shib IdP V5 does not have an embedded container,
you need to research, train yourself and then deploy your container before
you upgrade, and by the way support for Shib IdP V4 stops early next year".

Unlike Scott, I am not too worried by the support list cost, although I'm
prepared to be proven wrong.  As a data point the QuickInstaller for windows
(which is just a bootstrap to get the right things to the right place - and
explicitly does not address updates to any package) ships a stripped down
Tomcat and my memory is not having [m]any user support issues.  The major
pain has always been updating the distribution with the latest/greatest
Tomcat.  

My observation is that the cost of supporting IIS and Apache springs from
the open-endedness of the configuration - the user is fitting the SP into an
existing setup and 3 years ago someone decided (for instance) that the best
architecture was to have 5000 vhosts and a broken load balancer, then
someone else another badly installed a hand full of layered products and
tinkered with things further.  

To my mind an important point about bundling Jetty is that we are not
shipping a general container, we are shipping some carefully chosen jars
with a carefully chosen "Mandatory default" configuration.  If people tinker
with that then they are deploying their own container and they get a terse
answer about support.    The (very weak) analogy which struck me on vacation
was to OpenSSL - we ship OpenSSL dlls with the windows SP install, but we
don't support OpenSSL on windows - indeed it seems to me that we have more
pain about non-shib OpenSSL/curl on non Windows platforms than we do about
openSSL/Curl dlls on windows, precisely because we only care about a subset
(and we can circumscribe the use to be only us).

My support for the idea of co-bundling Jetty is really based on two drivers:

- Some discussions we had a long time ago which seemed to indicate that we
might be able to then ship upgrades via rpms for the Linux world.  I don't
speak Linux, but anything which will make it easier for people to keep up to
date has got to be a good idea.  It certainly seems to have helped people
keep up their SPs to date.

- Mostly I think about Windows where bundling seems very natural.  A
reasonably large proportion of these people (particularly in the UK) will
not run any other web service on the IdP host, and further they are not
large organizations:  meaning that their scalability and availability needs
can be served by an embedded Jetty, the sysadmin staff are so widely
stretched that they are never going to become jetty experts (indeed they
will struggle to become IdP experts).   I do *not* think that it is a good
idea, but I will float the idea of only bundling in a windows environment.

Tom asked:

> The idea of providing a v2 package with a co-bundled Jetty is
> interesting to me for the purposes of generating feedback

I would be extraordinarily keen to see this done in the Windows space.  None
of what follows is decided or committed but:
 - I should like us to move to WiX based Installers (preferably built as
part of the standard built, but if needs be built from the distribution
package - probably with a flow involving 'heat.exe')
 - I should *really* like to tie off the QuickInstaller cleanly (which was
one of those 'good ideas' which haunt you).  
 - Further I'd like to be able to offer V2 (and eventually) V3 as an upgrade
path from QuickInstall to standard install. 

So I'd agree that this feels like a good idea; but for windows I'd like to
make it more grandiose since it allows us (me) to get our head around all
the bullet points above and not do it in a rush at the end.  In project
management terms it is good risk management to get the bulk of this work
done sooner rather than later.  I do not envisage that a V3 (windows)
installer would represent a huge delta on effort from a V2 installer...  

FWIW

Rod