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?
Not sure why I assigned this to mazz, anyone one from the provisioning team could likely answer this question
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.
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?
(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).
Assigning to Deon so she can make sure this gets added to the docs.
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.
deon - has this been added to docs? ask mazz or jay if you've got questions
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.
Updated links: http://docs.redhat.com/docs/en-US/JBoss_Operations_Network/3.1/html/Admin_Deploying_Applications_and_Content/provisioning-apps.html#about-bundles http://docs.redhat.com/docs/en-US/JBoss_Operations_Network/3.1/html/Admin_Initial_Setup_Inventory_Groups_and_Users/chap-Basic_Admin_Guide-Importing_and_Organizing_Resources.html#inv-for-jon 2.4 should still be good: http://docs.redhat.com/docs/en-US/JBoss_Operations_Network/2.4/html/Basic_Admin_Guide/provisioning-apps.html#about-bundles
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.