AS7/EAP6 deployment resources for domain mode

Heiko W.Rupp hrupp at redhat.com
Fri May 16 12:52:46 UTC 2014


Hey,

Am 16.05.2014 um 14:32 schrieb Thomas Segismont:

> In domain mode, deployments appear at three different levels:
> (1) Domain deployments under the host controller resource

In fact this should be for the DomainController only.

> (2) Deployments under server group resources
> (3) Managed deployments under managed server resources



> 
> In the plugin descriptor, both resource type (1) and (2) have createDeletePolicy="both" (with creationDataType="content"), while (3) has createDeletePolicy="neither".

3) is only (for) the runtime information. The managed servers get that deployment from the local HC. There is (afaik) no way
to directly deploy to one of those or to remove a deployment of those. Those two operations are done via forming of
server groups and deploying to them.

> This is confusing because when you upgrade the content of a Domain deployment resource, you see a stale history of content in the Server Group Deployment resource (see Bug 889250 [1]).
> 
> Unless I missed something, users should only upgrade content of Domain deployment resource, and use the server group deployment resource to execute enable/disable/restart operations (deploy/undeploy/redeploy in AS7/EAP6 terminology).

The possibility to deploy via server groups is a short cut so that people do not have to first upload the content to the domain
(controller) and then assign that to a server group. 

> 
> I'm for creating a new deployment resource type, server group specific and unaware of the content aspects. Is there any major objection before I start the pull request?

What exactly do you mean here? 

Would that replace the existing types? How would a migration strategy look like for people that have a deploy workflow
already with the existing resource types?

  Heiko


-- 
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera



More information about the rhq-devel mailing list