Bug 604471

Summary: Whats the point of the Ant Bundle Handler resource type
Product: [Other] RHQ Project Reporter: Charles Crouch <ccrouch>
Component: No ComponentAssignee: Deon Ballard <dlackey>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: medium Docs Contact:
Priority: high    
Version: unspecifiedCC: hbrock, jshaughn, mazz
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-01 19:20:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 593121    

Description Charles Crouch 2010-06-16 00:57:06 UTC
It doesnt have any metrics or operations or configuration properties or connection properties. It just sits in the Autodiscovery Queue, begging for people to ask "What is an Ant Bundle Handler?" If its required can we make it a platform service so people don't need to import for every platform they upgrade?

Comment 1 Charles Crouch 2010-06-16 00:58:45 UTC
Not sure why I assigned this to mazz, anyone one from the provisioning team could likely answer this question

Comment 2 John Mazzitelli 2010-06-16 12:55:57 UTC
The point of the Ant Bundle Handler is just that - its the server resource that handles/processes Ant Bundles so they get deployed properly.

Yes it is annoying to have to import it - remember, we used the standard RHQ plugability to introduce Provisioning features to the agent, thus it requires us to write an agent plugin and deploy/import it just like any other RHQ plugin/resource.

We discussed how we can implement a new feature such that a "special" resource like this could be auto-imported. Having it as a child service to the platform is one way. That, however, would not hide the resource from the left-hand tree nav or any other part of the GUI (so your BZ could have also asked, "why do I see this Ant Bundle Handler resource in my tree or in my resource list?").

There are other things we could do (e.g. introduce a new mechanism by which a resource can indicate it should be "hidden" from the user's view - so it doesn't show in the UI). That would not be trivial - it would probably require a change to RHQ_RESOURCE schema to have a new column "hidden" and all our search queries would then need to add a "AND hidden = 'false'" clause.

In other words, the solution isn't as trivial as just making it a child service - that only solves the "why do I have to import this on all my platforms" problem but does not solve the "why do I see this resource on all my platforms in the GUI" problem.

Comment 3 Charles Crouch 2010-06-16 16:05:53 UTC
The problem with this resource type is that it is nothing at all related to what people have deployed in their environment, it is a piece of RHQ infrastructure. Outside of the RHQ Server and Agent resources I'm not aware of anywhere else we do this.

I presume not importing this resource disables the provisioning functionality for that platform?

If so, then we need to make sure this is doc'd and may be we should rename the type to something that indicates its related to our infrastructure and related to the provisioning feature, e.g.  "RHQ Provisioning Plugin". Then if people don't want provisioning they can ignore this resource. We're also going to need to test how the provisioning stuff fails when this resource isnt imported.

Do we expect to have more of these resource types in the future?

Comment 4 John Mazzitelli 2010-06-16 16:31:01 UTC
(In reply to comment #3)
> I presume not importing this resource disables the provisioning functionality
> for that platform?

correct.

> If so, then we need to make sure this is doc'd 

It is somewhat doc'ed in the community wiki here:

http://rhq-project.org/display/JOPR2/Provisioning#Provisioning-SupportedBundleTypes

where it says: "Today, there are two bundle types that can be supported, ***if you choose to deploy their respective agent/server plugins***" (my *** emphasis). We don't explicitly mention the resources and that you have to import them. Note that these docs were just something I wrote up as a starting point - we need people to build out these docs.

> and may be we should rename the
> type to something that indicates its related to our infrastructure and related
> to the provisioning feature, e.g.  "RHQ Provisioning Plugin". Then if people
> don't want provisioning they can ignore this resource.

We can rename them. Today we have "Ant Bundle Handler" and "File Template Bundle Handler" which, I thought, would have been descriptive enough - e.g. they "handle" the "bundles" of type "ant", hence "Ant Bundle Handler" :) If you want the word "Provisioning" in there as opposed to Bundle, we can do that. Of course, recall that the word "Bundle" is found in lots of places in the docs and UI so we'll want to make sure we are careful to maintain some consistency.

> Do we expect to have more of these resource types in the future?    

RHQ has the second "File Template Bundle" plugin. We could, in the future, have say a "Puppet Bundle" plugin , a "Chef Bundle" plugin or even a "Cobbler" plugin (whose recipe is merely a kickstart file).

Comment 5 Charles Crouch 2010-06-17 17:27:25 UTC
Assigning to Deon so she can make sure this gets added to the docs.

Comment 6 Jay Shaughnessy 2010-06-28 21:01:10 UTC
Note on commit 5c1112f7c170af81986456808ba1fee557c58036:

The "Bundle Handler - Ant" resource is now a Service under Platform resources. It was formerly a Server category resource.  This means that the user will no longer have to manually import the resource.  The bundle handlers will be importer automatically and therefore provisioning will be enabled out of box.  The
handler resources will still be visible as children of the platform.

Comment 7 Corey Welton 2010-12-16 13:19:41 UTC
deon - has this been added to docs? ask mazz or jay if you've got questions

Comment 8 Deon Ballard 2010-12-16 16:53:22 UTC
Nope, I didn't add anything. I thought the commit in comment #6 meant no docs were necessary. I'll follow up with Jay and Mazz to see what's required.

Comment 11 Heiko W. Rupp 2013-09-01 19:20:52 UTC
Bulk closing of BZs that have no target version set, but which are ON_QA for more than a year and thus are in production for a long time.