Hi, Tim
Thanks for writing this up!
One enhancement that we have discussed which will be needed for the
new scheme is the ability to enable/disable application at cluster
instance level.
In v2 and previous releases, all the application lifecycle commands
(deploy, undeploy, disable, enable) are done at cluster level, and not
at cluster instance level. It should not be too hard to support
enable/disable command at cluster instance level from deployment point
of view, but I am not sure if there are any implications on other
components like config. For example, are there any bean validation
associated with cluster config elements which force all the cluster
instances to have the exactly same configuration?
Also will there be any implications on admin gui now we need to
support enable/disable at cluster instance level?
Just wanted to hear people's thoughts on this.
> 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.
(I think if the --target is specified as domain, it will be redeployed
to all the previous targets).
- Hong
> 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