Re: [JBoss-dev] Tomcat 6 redeploy.

[Jason T. G. <jas...@jb...>]

I thought I would clarify because my lost post sounded rather jerkish.
(sorry).

I am not disagreeing that code stability is not a higher priority.

What my point is, is that the concept of facilitating updates that
minimize the downtime of an application is not flawed. I see your point
in that the added complexity makes software stability harder to achieve,
but that is an implementation issue (our job to make sure it works
well).

Also, there are also ways to build a good methodology into the software.
For example, there is no real reason why pulling a node out of a load
blancer pool, and deploying a new application has to be two manual
steps. Although, it could be argued that deploying to every system at
the same time is risky, so in that case you could design a tool that
would allow the administrator to step the deployment process through
each node. In this way they can verify that everything is still ok after
each update. This type of management is very reliable and very
predictable, because there is still some human intervention.

-Jason

> -----Original Message-----
> From: Jason T. Greene
> Sent: Thursday, June 29, 2006 4:40 PM
> To: Remy Maucherat; Sacha Labourey; Robb Greathouse; Stan Silvert;
Ryan
> Campbell; 'JBoss.org development list'; Scott M Stark
> Cc: The Core; Bill Burke
> Subject: RE: [JBoss-dev] Tomcat 6 redeploy.
>=20
> > -----Original Message-----
> > From: Remy Maucherat
> > Sent: Thursday, June 29, 2006 4:00 PM
> > To: Sacha Labourey; Robb Greathouse; Stan Silvert; Ryan Campbell;
> > 'JBoss.org development list'; Scott M Stark
> > Cc: The Core; Bill Burke
> > Subject: RE: [JBoss-dev] Tomcat 6 redeploy.
> >
>=20
> -snip-
>=20
> > Maybe these techniques will be implemented eventually, but given the
> > target users need mature stuff, it's going to take a long time
overall.
> > It's quite simple: users who want to use a cluster usually want the
best
> > quality of service, while at the same time generic automagical
features
> > like these ones add complexity and unpredictability. If you'd like,
you
> > can try and sell this sort of deployment methodology to the DGI, for
> > example ;)
> >
> > There are some issues at the moment in mod_jk about quality of
service,
> > that are a technical prerequisite to all of the fancy marketing
friendly
> > features, so we're going to start there.
>=20
> There are ways to do this in a very predictable manner.
>=20
> Although, I would be curious to hear your solution for achieving 5 9's
of
> uptime while still allowing updates.
>=20
> -Jason