[jboss-as7-dev] HASingleton deployment

[Stuart Douglas]

Paul Ferraro wrote:
> ----- 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.
>

I don't think this really does help in that case. Either way the person 
doing the deployment has to know to do a ha singleton deployment, rather 
than a normal deployment.

Stuart

>> 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
>>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev