On Thu, 28 Apr 2011, Aaron Fuleki wrote:
On Apr 27, 2011, at 2:33 PM, Marvin Addison wrote:
Question remains: would anyone deploy a VM appliance to their
production architecture? Please, please, speak up if you're willing
and under what conditions.
For the love of all that is good in the world, yes!
There are a lot of smart folks on this list, who work in shops with
dedicated infrastructure teams, or who have ninja-level Java application
development/deployment skills. I think you guys are awesome, and I've
probably bought you many a beer at conferences and meet-ups, while I ask
seemingly inane questions :-)
I'm from a small school, with a small shop. In my experience, a small
team in a heterogenous environment can't afford to have (or maintain)
the depth of knowledge it takes to config, deploy, and maintain complex
apps like CAS from the source and bare metal. When even your programmers
take support calls in the field, you can run out of hours in a day
pretty quickly.
If there were some well documented, easy to setup CAS VMs that covered
common use cases, I'd use them in a heartbeat, for both testing and
production. I'd probably have _fewer_ security concerns with a
publicly-vetted config over my own. Heck, I wouldn't mind replacing our
uPortal server with a generic virtual appliance. I'd love to just pick
the flavor of VM(s) closest to my scenario (standalone, LDAP, Services
Manager, Distributed Ticket Registry, etc.)., provide some details,
point it at a database, and maybe a theme to load, then deploy. I don't
care about the OS, the architecture, etc.; I'd never even look at it as
server to support, just a service. Other than security patching, it'll
go months or years without getting dedicated staff eyes on it again.
I appreciate how little I probably understand the massive amount of work
it would take to develop production-quality generic CAS appliances, for
even the simplest configuration scenarios. Also, I'm wary of putting
too much stock in my own opinion, as I'm just one voice. However, I'm
equally wary of the responses on a list where the most active
participants are not the target audience. Jasig projects, and community
source movement in general would probably benefit from lower costs of
entry and maintenance. That's not a dig, just a thought.
To me, this sounds like a strong reason to simplify the deployment of CAS
in general.
I was new to CAS a few months ago, and it was much more difficult to get
working that any other application I have deployed lately. When our
internal web programming team gives me an application, it typically has 1
or 2 config files to modify, and they come well-commented and with
sensible defaults.
I realize that CAS has a lot of options, but the configuration is spread
out among a huge number of files. Before I can even get to that part, I
had to figure out Maven and what to put in my pom.xml. And pom.xml is one
of my biggest beefs... CAS should distribute a pom.xml for each version
of CAS. The dependencies should be well-documented for, at least, the
major common configuration choices (LDAP, Hibernate, Memcache?) so that I
don't have to figure out which versions of 4 different Hibernate jars I
need. This gets tricky when CAS pulls in dependencies automatically, but
they are incomplete or have conflicting version requirements.
Now that I have it working, I can understand how it all fits together.
Still, my Maven overlay has 7-10 different configuration files to use LDAP
authentication plus a database ticket registry. Complexity hurts.
I hope I'm not the only one that struggled to figure all this stuff out!
There is a steep learning curve for those of us without a Java background.
If I'm doing any of this the wrong way or just being stupid, feel free to
let me know. :)
Andy
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
