Hi, everyone.
I've created this page
http://wiki.glassfish.java.net/Wiki.jsp?page=V3.1RollingUpgrade
with some initial discussion about the rolling upgrade piece of
cluster support in 3.1. I've written only about how app versioning
can help simplify the process in GlassFish 3 vs. 2, but more could be/
should be added to the page. (It seemed that rolling upgrade would
merit its own page, but if others feel the content belongs on one of
the other existing pages that's fine with me.)
I've posed a question there which I'll repeat here:
GlassFish 2 required an administrator to redeploy an app to the same
instances where it already resided. Normally for clusters this was
natural because the admin would specify the same cluster name for the
deployment and the redeployment...or if --target was omitted from the
redeployment GlassFish automatically used the targets where the app
was deployed.
Currently we have no similar restriction in the app versioning
proposal. That is, we don't currently mandate that a new version of an
app be deployed to the same target(s) where its predecessor is already
assigned. I don't think we want to do that, because it seems like a
valid use case to deploy one version of an app to one target and
another version to another target (for testing, training, etc.).
Instead, GlassFish 3.1 could warn if the user deploys a subsequent
version of an app to a different set of targets from the set where
it's already deployed. That would create "noise" in the example above
- where the admin wants one version on one target and another version
on another target - but the example would be allowed. And in the case
where the administrator intended to hit the same targets but didn't
the warning would alert him or her to that.
Thoughts?
- Tim