Skip to end of metadata
Go to start of metadata

When you want to define a dynagroup, you can either type in the expression yourself or compose them via the wizard. A third alternative for common cases is to use canned expressions:

Unfortunately those expressions are hard coded in the server(1) and can't easily be added to by 3rd parties

1) Technically speaking in org.rhq.coregui.client.inventory.groups.definitions.SingleGroupDefinitionView#getTemplates

Proposal

We should put the definitions into the plugins so that plugin developers can define standard canned expressions, which can then be displayed in the servers list of expressions.

Format

The expressions should live in their own file inside plugin.jar!META-INF/ and not be part of the plugin-descriptor, as the latter one is already too big and complicated. We should update the plugin verification tool in a way that a developer can cross check that the names for types and metrics in the expression match the ones from the descriptor.

The format of the template could be anything - I would expect not to use XML, as any of those reserved chars like <,>,& etc.
would need CDATA sections

JSON or Yaml come to mind. The following shows an example on how this looks like in JSON:

Inside the individual expression, we would have a name/description that is shown in the drop down and the template text. In the above example individual lines of the template are put into elements of an array of strings that is then (literally) put into the editor textbox.

As more than one plugin could define an expression with the same name, we need to make sure that the display for the user includes the plugin name as first part of the name (if we stay with a dropdown); if we create a more sophisticated editor, we should allow to sort by plugin name and expression name.

The above example contains two more entries that may need explanation:

  • deployByDefault : if this is present and set to true, then we will on deploy of the plugin create a DynaGroup from the entry. And probably also:
  • recalcInMinutes: automatically recalculate the expression every given minutes. A value of 0 switches recalculation off. Only positive integer values are allowed

Server side storage

We could store the expressions in the database in a separate table (possibly just the whole JSON string in a clob). Deploying a new plugin would add new templates, update existing and remove ones that are no longer in the plugin. As alternative we could also leave them in the plugins and dynamically populate the dropdown / list of templates from the plugins when the user wants to create a new DynaGroup. This is possible as we do not relationally refer to the templates, but copy their content when the user selects one.

UI handling

As the list could grow large with many plugins, we should think of allowing to filter entries

  • by name
  • by plugin

As we already have the DynaGroup-Wizard and the input field to write such expressions, a user with INVENTORY_MANAGER could get additional buttons and fields to store such an expression and also remove user generated expressions. The user generated expressions could get a "plugin name" of "User" (or " User" to sort them in the list to the top). or similar. Also we must make sure that the canned expressions will now show the delete button.

Agent side handling

Agents do not need access to the dynagroup expressions, so they do not need to touch or parse that descriptor

Lifecycle on the server

When a plugin is parsed on the server, the canned expressions are just added to the list of available expressions if they are not yet there. If they already exist, they are replaced. Expressions for a plugin that are no longer provided by the plugin are deleted.

When a plugin is deleted (removed, purged, killed) the expressions of it are removed - especially as killing a plugin also removes all its resource types and resources of that type.

User defined expressions just stay until the user cleans them up.

Questions:

  • Should the user be allowed to define such canned expressions on his own: YES
    • If yes: how can an end user define entries on his own? One possibility could be to write an empty plugin that just holds those values.
    • Use some additional UI elements to save / delete what the user has provided in the textfield
  • Should a template with deployByDefault=true be deleted on plugin undelete? If the resources defined by the plugin are gone, the expression is probably no longer needed: YES
  • Should a template with deployByDefault=true be hidden from the user? I think the user may still want to use that as a template for his own trials, so we should offer it, but without any automatic recalculations
Labels:
dynagroup dynagroup Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Dec 11, 2013

    I would probably try to avoid the use of the word "template" as it implies something that can be defined or modified by the user. In this case, it is simply a UI component or a built-in dynamic group definition provided by the plug-in itself.

    The implementation should ensure that template names or identifiers are unique. In this case these are coming from a plug-in so using the plug-in name could provide this assuming the UI would display this in a logical manner.

    • How can an end user define entries on his own? One possibility could be to write an empty plugin that just holds those values.

    For developers, an empty plug-in seems like a good place. But for users, assuming we want to actually provide templates, then I would expect that these could be defined using the same steps that are used to define a dynamic group with the addition of a "save as new template" option. Additionally, selecting an existing user defined template would add a "save template" option to update the existing template with the changes.

    • Should a template with deployByDefault=true be deleted on plugin undelete? If the resources defined by the plugin are gone, the expression is probably no longer needed

    I am assuming you meant with plug-in delete? In that case, yes. assuming that the resources are actually deleted and not being hidden then it wouldn't make sense to keep the dynamic groups around or the plug-in's built-in dynamic group definitions.

    • Should a template with deployByDefault=true be hidden from the user? I think the user may still want to use that as a template for his own trials, so we should offer it, but without any automatic recalculations

    I don't think it should be hidden. However, perhaps another attribute can be provided called "hidden" which if set to true would prevent the user from seeing this as a built-in dynamic group definition. In such cases, maybe hidden=true implies deployByDefault?

    1. Dec 13, 2013

      • How can an end user define entries on his own? One possibility could be to write an empty plugin that just holds those values.

      For developers, an empty plug-in seems like a good place. But for users, assuming we want to actually provide templates, then I would expect that these could be defined using the same steps that are used to define a dynamic group with the addition of a "save as new template" option. Additionally, selecting an existing user defined template would add a "save template" option to update the existing template with the changes.

      There's a couple of things here - unambigous naming of the templates, the ability to CRUD new ones but also the organization and "searchability" of the templates.
      I share Larry's opinion on "writing an empty plugin to hold those templates", i.e. I don't particularly like it. The link from the template to the plugin that defined it needs to be there so that we can actually delete the templates when a plugin is deleted but I don't think it is of much interest to the user. Or maybe it would but then where would we "slot" the user-defined templates? Under "User defined"? What if the user created a template that would logically belong to the AS7 plugin because it only deals with resource types defined there?

      IMHO, if we assume that the number of dynagroup templates won't be higher than say 50 in a typical installation, I'd not bother with anything more than including the name of the plugin in the name of the template (in an attempt to provide unambiguous names) and providing just a dropdown of all templates as we have now.

      If we anticipate more templates than that then grouping them by plugin and slotting the user defined under "User Defined" is certainly one of the options but I don't like the "catch-all" nature of the "User defined" slot. In that case, we maybe could allow assigning additional templates to plugins (should these be deleted with the plugin too, then?) or keep the list of templates flat but come up with some more elaborate search (maybe just full-text on the names + the expressions themselves?).

      • Should a template with deployByDefault=true be hidden from the user? I think the user may still want to use that as a template for his own trials, so we should offer it, but without any automatic recalculations

      I don't think it should be hidden. However, perhaps another attribute can be provided called "hidden" which if set to true would prevent the user from seeing this as a built-in dynamic group definition. In such cases, maybe hidden=true implies deployByDefault?

      Why would we want to hide the templates from the users even if the dynagroups were auto-created from them? I think I agree with Heiko, we should offer them. I'd go as long as pre-filling the recalc interval according to the template when the user creates a new group from that template. I think it can be understood as the recommended default provided by the plugin writers.

      We should, IMHO, also make the plugin-defined templates read-only and not deleteable, unlike the user-defined ones. Then there's of course the question of permissions for CRUDing templates, but since currently only {{INVENTORY_MANAGER}}s can create groups (if I'm not mistaken), I think they are powerful enough to deal with group templates, too.

  2. Jan 20, 2014

    Might also want to add a question for discussion regarding "timing" and "which release".   If there is an change to the plugin API ... or if the change requires plugin owners to do some rework ... then the timing of this change might be important.  

    1. Jan 21, 2014

      As for release I guess RHQ 4.11.
      And the implementation will not touch plugin api or plugin code.
      Plugin owners do not need to do anything if they do not want to offer this new feature.

  3. Jan 20, 2014

    I don't like the word "template". "Canned Expression", "Provided Expression" or the current "Saved Expression" is better, although the latter is a little misleading.

    One thing I'm not sure about with the plugin-provided expression idea is where we should put the plugin-independent expressions (e.g. "unique resource types in inventory"). Perhaps we could just put them in the Platform plugin.

    I don't like the idea of having to deploy an empty plugin for user-defined canned expressions. Do we really even expect user-defined canned expressions? I'm not sure I really see the point. Why define a canned expression and then use it to build a regular definition? Even if it were useful, I think defining it in the GUI and saving it via a new button is viable.

    For the plugin-defined expressions, I suggest an internal-name (unchanging) and a display-name. This will help with meta-data update.

    Has there actually been a request for deployByDefault? What is the use case? I'm a little leery of plugin developers causing end-user impact. Generating unexpected groups could be confusing.

    1. Jan 20, 2014

      One of the use cases for deployByDefault, I think, would be automatic mapping of Wildfly's server groups and domains by our groups.

      1. Jan 21, 2014

        Exactly

    2. Jan 21, 2014

      I used the current naming, as the Wiki page requires a name and also to transport the idea that the expression is coming from the plugin. "Predefined expression" may be another way. We may talk to some UX expert on which is to be understood best. Also at other projects to see what they do.

      I was throwing in the empty plugin idea for those expressions, as this would have fitted the "normal workflow". I have updated this proposal since with the UI-only option for user defined expressions.

      The use case for deployByDefault is indeed as Lukas wrote the pre-definition of "server group", "group of standalone as7", "group of domain/host controllers" and so on, which is requested a lot and which should make it more easy for users to get started.

      1. Jan 31, 2014

        "Predefined expression" << +1

        "UI-only option for user defined expressions" << +1

        Just a comment on the JSON format: it doesn't clearly indicate what "deployByDefault" and "recalcInMinutes" mean. How about: