This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 536563 - (RHQ-8) Plugin config templates
Plugin config templates
Product: RHQ Project
Classification: Other
Component: Plugin Container (Show other bugs)
All All
medium Severity medium (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2008-02-27 18:22 EST by Greg Hinkle
Modified: 2014-05-15 17:30 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-05-15 17:30:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
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
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.

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