Description of problem: One of the available Automation entry points for a Button and Simulation is /System/Process/Event. With the advent of the the Event Switchboard this seems to make no sense any more as there is no EventStream object passed with the request. If I try to use this simulation entry point I get: Error during substitution: undefined method `event_namespace' for nil:NilClass Error during substitution: undefined method `source' for nil:NilClass I suggest we either remove 'Event' from the drop-down list or allow an EventStream object to be selected in the Simulation Object Attribute 'Type' drop-down list. It probably needs to be removed from the Button option as well (in fact when would a button ever run anything other than /System/Process/Request?) Version-Release number of selected component (if applicable): CFME 5.5.2 How reproducible: Every time
I have two thoughts/questions around this: 1) These are area of the product used by admins/developers to test and configure the system. Is there really much of a need for this type of protection here? 2) The current drop-down lists all the instances in /System/Process across the applicable automate domains. Users can add their own instances to the namespace which may be unsuitable for calling from a button or simulation. Is the suggestion that we should protect against these as well, and if so how? It is true that previously the event instance only needed a name and now it requires an object to process properly. This change was required to support the switchboard logic and allow event objects to be broken down into namespaces for grouping and processing. A user today could pass an existing event object as part of the "Attribute/Value Pairs" and properly execute that against the /System/Process/Event instance. I agree with the idea of exposing the ability to select an existing event object to run against in Simulation. It would require some new logic to drill into a provider or other object to select the event. At a high level I am trying to understand if locking down an open-ended system makes much sense, or if maybe there is a different way to approach this. Do we need to start tagging the automate instances that can appear in these areas of the UI? I also think about how the UI for selecting the Service entry-point was locked down to state-machine instances only and users have asked for that to be opened up to allow for other selections. This feels like a similar issue to me. It seems useful on the surface but someone always has a use case to expose the full system. Tina commented after seeing this ticket that she wanted to add "parse_provider_category" to the list as well, so maybe it is just me. Thoughts?
All good points, and I agree, "parse_provider_category" shouldn't be there. My view is that the menu item is under Automate -> Simulation, and so the majority use-case is likely to be the simulation of relatively simple 'normal user' Automate scripts. The defaults should reflect this, currently it's confusing. Having worked with many customers who are learning automation, they like the simulation feature, but invariably forget to select 'Request' in the drop-down, and also forget to tick 'Execute Methods'. Maybe we default/grey out the 'Object Details' entry point to be /System/Process/Request (with 'Execute Methods' ticked by default!), but then have something like an 'Advanced' or 'Developer Mode' checkbox that makes the other /System/Process entry instances available?
I like the suggestion to make different modes where the default mode is the common use case (/System/Process/Request with Execute Methods enabled). Redirecting this ticket to the UI team. John - Can you please review the suggested changes and validate this request.
Updated defaults implemented in PR https://github.com/ManageIQ/manageiq/pull/9979 Trello: https://trello.com/c/QxcgpkJf
Milan - I think this BZ/PR should focus on the changes to Simulate. We can address the custom button change in a followup PR.
Verified then.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2016-1634.html
Can we get this added to the "Adding a new Button" dialog as well (as originally requested)? This still shows /System/Process/Automation as the default. Thanks, Peter