Bug 536563 (RHQ-8)

Summary: Plugin config templates
Product: [Other] RHQ Project Reporter: Greg Hinkle <ghinkle>
Component: Plugin ContainerAssignee: RHQ Project Maintainer <rhq-maint>
Status: CLOSED WONTFIX QA Contact: Mike Foley <mfoley>
Severity: medium Docs Contact:
Priority: medium    
Version: 0.1CC: ccrouch, jshaughn
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: All   
URL: http://jira.rhq-project.org/browse/RHQ-8
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-05-15 17:30:16 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Greg Hinkle 2008-02-27 18:22:00 EST
So, Plugin components have plugin configurations that they use to perform the management. These configurations are often defaulted by the plugin writer so that auto-discovery can do useful things, but sometimes the defaults are different for an environment. (e.g. a default setup for a certain type of application deployment within an enterprise) By letting the user edit what is the default configuration values for the plugin component they can control more what happens around auto-discovery and perhaps choose in a broader context, which features of a plugin they would like to use. Another example would be a plugin configuration to disable the discovery of deployed packages on a resource. Perhaps the user isn't interested in tracking the RPMs installed on their rhel boxes. A plugin config property to enable/disable this discovery combined with the plugin config template would give the admin full control
Comment 1 Charles Crouch 2008-02-27 18:34:29 EST
Not sure this feature could be extended to support this but an option to disable/enable a plugin by default would fix RHQ-1
Comment 2 Joseph Marques 2008-07-21 01:36:26 EDT
this sort of sounds like you want an auto-discovery "profile" to be applied to particular resources at import-time.  for each to-be-imported resource, the user is presented with a list of profiles for that resource type to chose from (profiles which can be tweaked, or new ones added per resource type via a separate part of the UI), and selects one for the import.  assuming we implement this across the board, there would be at least one profile for each resource type, which would be selected by default.

fyi - i could see this being very useful to import, say, resources that have security turned on.  if the plugin configuration needs to know about principal / credentials, then a security-enabled profile can be created (and set as the new default for that resource type) which would be applied to all imported resources.  this way, they get inserted into the inventory and are discovered as available (green) instead of unavailable (red).  granted, the fact that we support efficient group plugin configuration updates lessens the importance of this jira, but this is still an excellent feature request.
Comment 3 Red Hat Bugzilla 2009-11-10 16:19:14 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-8
Comment 5 Jay Shaughnessy 2014-05-15 17:30:16 EDT
Not the same thing, but type ignore is likely as far as we'll get with this idea. Closing this due to inaction.