Bug 536331 (RHQ-693)

Summary: RFE: Dynamic Configuration Property Enumerations
Product: [Other] RHQ Project Reporter: Greg Hinkle <ghinkle>
Component: ConfigurationAssignee: RHQ Project Maintainer <rhq-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.0.1CC: ccrouch, hrupp, jshaughn
Target Milestone: ---Keywords: FutureFeature
Target Release: RHQ 4.9   
Hardware: All   
OS: All   
URL: http://jira.rhq-project.org/browse/RHQ-693
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-30 12:49:06 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:

Description Greg Hinkle 2008-07-21 13:47:00 UTC
This mechanism allows the plugin to supply overrides for the list of options of a property definition. For example, if your configuring a jms topic and want to give the user a drop down of the datasources that are available to use as persistent stores. Anything were the list of options is completely dynamic or should be restricted by logic given the context. The communications with the plugin should include the entire configuration state, likely after each property is altered or on specified dynamic properties to allow a model similar to the javascript form selection for interdependent fields. (should this also support field disablement?)

Comment 1 Joseph Marques 2008-07-22 03:31:08 UTC
interesting feature request.  i agree that dynamic config elements make config stuff even more powerful, but i'm not sure i see the ROI for supporting cascade rules across fields.  the flow is already rather complex: before config ui renders, it realizes that it needs to query information from the agent-side, so it makes distinct requests to it, which in turn potentially query the managed resource for information, information is passed back up to the server-side, and after all responses are known the config ui component can finally render the response.

some thoughts / questions:

* if we don't support cascading rules, then it's quite easy to cache the dynamic results after they are gotten from the agent the first time.  the page will only be slow on initial load, and after that the user can edit lists/maps as well as perform any other multi-page flows without needing to talk to the agent again.

* is there a way to pre-load this data before the user goes to the config ui page, maybe at import-time, or some other sufficiently advanced time?  i'm guessing no because dynamic properties can be based off of just about anything right?

* is there a way to make this a complete server-side implementation, where the user given access to some sort of restricted data model through a simplified, dynamic config property DSL (similar to what the embedded CLI might look like)?

* how should this work if the agent is down, or the manage resource that the agent needs to talk to is down?  in this case, i think the UI would either fail to render, or would render an empty list - both of which aren't very helpful...unless of course we could pre-fetch this data when we know it was available, or if the implementation was completely server-side.

Comment 2 Red Hat Bugzilla 2009-11-10 21:14:54 UTC
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-693


Comment 4 Jay Shaughnessy 2014-05-15 20:51:55 UTC
Heiko, I swear we had something like this but maybe not...

Comment 5 Heiko W. Rupp 2014-06-30 12:49:06 UTC
Yes, this is in now in 2 ways
- you can say "get the value from a database table"
- you can get the values from other resources via "<c:option-source>" See https://docs.jboss.org/author/display/RHQ/Notes#Notes-Optionsource%7B%7B%3Cc%3Aoptionsource%3E%7D%7D