[jboss-as7-dev] HASingleton deployment

[Paul Ferraro]

----- Original Message -----
> From: "Brian Stansberry" <brian.stansberry at redhat.com>
> To: "Paul Ferraro" <paul.ferraro at redhat.com>, "jboss-as7-dev at lists.jboss.org Development"
> <jboss-as7-dev at lists.jboss.org>
> Sent: Thursday, September 13, 2012 8:27:25 PM
> Subject: HASingleton deployment
> 
> Moving a discussion to the dev list.
> 
> Paul, using parallel operations instead of storing metadata with the
> deployment resource itself has a couple drawbacks:
> 
> 1) On restart of the server the special handling information implicit
> in
> the parallel deployment ops is lost and the deployment becomes a
> non-singleton.

I didn't mean to imply that these operations would create plain deployment=* resources - rather these separate operations would create separate resources representing singleton deployments.  e.g. singleton-deployment=*

This keeps the two types of deployments, I think, appropriately segregated.  This would prevent, say, someone starting a deployment (a typical operation) on a node even though some other node is designated master.  Also, the management console would want a separate section to display singleton-deployments, indicating the status of a given deployment on each server.

> 2) In a managed domain, the "special" operation can propagate to the
> relevant servers in the domain at the time it is invoked, but
> subsequent
> to that if another server is added to a server group that runs this
> deployment, again the special handling information is lost.

Again, the processing of an singleton-deployment resource would take care of this.

> The stuff Thomas is working on that I mentioned is at
> https://github.com/jbossas/jboss-as/pull/2790.
> 
> On 9/12/12 12:17 AM, Paul Ferraro wrote:
> > I did spend some time thinking about while staring
> > out at the Mediterranean Sea this past week.
> > Fundamentally, implementing singleton deployments simply requires
> > wrapping the corresponding Service<DeploymentUnit> in a
> > SingletonService<DeploymentUnit>.  The effect is the deployment
> > unit will be installed on all nodes in the cluster, but will start
> > on only 1 node at a time.  The end result is more agile than what
> > we had in EAP5, since we're only starting/stopping existing
> > services, not creating them from from scratch.
> >  From a domain model perspective, rather than tack on configuration
> >  meta data to the deployment resource itself, I think it would be
> >  simpler/cleaner to provide a parallel set of
> >  deploy/undeploy/redeploy operations.  The deploy/redeploy
> >  operations will accept additional optional parameters for cluster
> >  name and node preference (for a preferred node election policy).
> > For standalone mode, it might still be nice to provide a separate
> > file scanner using a distinct location that creates singleton
> > deployments.  To clarify, this doesn't mean making the deployment
> > scanner itself a singleton service, but rather the operations
> > created by the scanner will install singleton deployment units
> > instead of normal deployment units.
> >
> > Thoughts/comments?
> >
> > Paul
> >
> > ----- Original Message -----
> >> From: "Brian Stansberry" <brian.stansberry at redhat.com>
> >> To: "Paul Ferraro" <pferraro at redhat.com>
> >> Sent: Wednesday, August 29, 2012 1:05:19 PM
> >> Subject: HASingleton related issues in the EAP 6.1 PRD
> >>
> >> Care to comment on $subject at
> >> https://docspace.corp.redhat.com/docs/DOC-105593 ?
> >>
> >> As I commented, I don't want to see an EAP 5-ish solution based on
> >> activating a scanner when a node becomes master. That would be a
> >> standalone-only hack. I think something along the lines of
> >> associating
> >> some configuration metadata with the deployment=* resource in the
> >> management model makes more sense, and then some clustering
> >> integration
> >> to "(de)activate" the deployment.
> >>
> >> If you agree, we should chat about this a bit on the jboss-as7-dev
> >> list
> >> before you go. The "associating some configuration metadata with
> >> the
> >> deployment=* resource" part intersects with some stuff Thomas
> >> Diesler
> >> was trying to do, and the "activate the deployment" part
> >> intersects
> >> with
> >> some stuff Stuart Douglas was working on, as well as some OSGi
> >> stuff.
> >>
> >> --
> >> Brian Stansberry
> >> Principal Software Engineer
> >> JBoss by Red Hat
> >>
> 
> 
> --
> Brian Stansberry
> Principal Software Engineer
> JBoss by Red Hat
>