Bug 707228 - Provisioning enhancements
Summary: Provisioning enhancements
Alias: None
Product: RHQ Project
Classification: Other
Component: Provisioning
Version: 4.0.0
Hardware: Unspecified
OS: Unspecified
unspecified vote
Target Milestone: ---
: ---
Assignee: John Mazzitelli
QA Contact: Mike Foley
Keywords: Reopened
Depends On:
Blocks: jon3
TreeView+ depends on / blocked
Reported: 2011-05-24 13:12 UTC by Charles Crouch
Modified: 2015-02-01 23:26 UTC (History)
4 users (show)

Clone Of:
Last Closed: 2013-09-02 07:23:17 UTC

Attachments (Terms of Use)

Description Charles Crouch 2011-05-24 13:12:18 UTC
Tracker for enhancing the bundle/provisioning subsystem. Work includes
-Add support for deploying to single resources, rather than just groups
-Add support for deploying to JBAS instances

Comment 1 John Mazzitelli 2011-05-26 20:19:08 UTC
"-Add support for deploying to single resources, rather than just groups"

That was in the very original design, but we purposefully decided against it and changed it to be group-oriented only (I'd have to go back to see if I can find notes on why I decided against it). Changing this to go back to individual resource deployments will potentially effect a lot - from the db schema to the server SLSBs.

Comment 2 Charles Crouch 2011-08-11 03:47:35 UTC
Mazz, can you update this issue describing the work you have done and push it 
to QA

Comment 3 John Mazzitelli 2011-08-11 13:21:21 UTC
-Add support for deploying to JBAS instances

There is now the ability to target bundles directly to JBossAS resources. If your group is a compatible group and its type is JBossAS, you can deploy directly to the JBossAS under its Deploy Directory or Install Directory - the user gets to choose directly on the UI which one they want.

-Add support for deploying to single resources, rather than just groups

Even though you can't target single resources explicitly, the bundle deploy wizard now makes it very easy to build new groups on the fly directly from the wizard and you can select a single resource while doing so. You click the "new group" button from the wizard, and from there you get a selection dialog box from which you can select a single resource and click "OK". Essetially, this is what you would be doing ANYWAY if we were to support explicit deployment to a single resource (you would still have to go through some UI workflow and click-through to select the resource you want). But here, that UI workflow creates a group for you and that group (which can contain a single resource if you want) is what it used to deploy the bundle to.

Comment 6 Sunil Kondkar 2011-09-21 11:59:04 UTC
Verified on Version: 4.1.0-SNAPSHOT Build Number: 7739090

Verified deploying bundle to JBoss As server instance with options 'Install Directory' and 'Profile Directory'. Also verified deploying to single resource by using the "new group" button from the bundle deployment wizard and selecting a single resource.

Marking as verified.

Comment 7 John Mazzitelli 2012-01-06 17:33:58 UTC
I took the time to see if I can find any history behind the decision to support only groups for bundle deployment. I don't have any definitive notes, but the decision appears to have been made in or around May 2010.

This diff to the wiki page is around that time (this doesn't have much to go on though):


Here is the schema design prior to the decision (I think this schema supported resource-only deployments):


and this is the new schema that supports group-only deployments:


here's the history of the image attachment - you can see the schema design through history:


Notice that group and resources were linked to a single relationship rhq_bundle_res_deploy (so this had one "res_deploy" table but it had linkage to either resource OR group). In schema-6, we ripped that duality out and added the concept of the destination which had a single relationship to group. The issue was being able to cleanly support the cases where you either had a resource (or disparate set of resources) linked to a bundle, vs. a group. Obviously, we'd prefer the user use an actual group than use a set of disparate and individual resources when linking to the bundle (think of how we would have to support that in the UI - we'd need a way to select a "group" of resources and assign them to the bundle but not use groups - doesn't make sense, we already have the concept and implementation of compatible groups - hence we just used that and shared the concept with bundles). That leaves us with the question of how to support the use-case of deploying to a single resource. I believe the thinking was, why introduce this complex and harder to maintain duality for a use-case that will be rare (deploying bundles to a single resource - back then, we were envisioning the bundles subsystem to be mainly useful to people who wanted to push out software to clusters of machines - not just individual one-off installations). We didn't think it was that important to support the concept of deploying to a single resource, when we could already support that with a group containing a single resource in it. Thus, because we CAN support that use-case WITHOUT introducing the duality of relationships, we decided to not allow resources to be explicitly related to bundles - we do it implicitly through resource destinations-groups.

Comment 8 Heiko W. Rupp 2013-09-02 07:23:17 UTC
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.

Note You need to log in before you can comment on or make changes to this bug.