Bug 1316842 - /System/Process/Event should not be displayed as a valid entry point for Automate Simulation
/System/Process/Event should not be displayed as a valid entry point for Auto...
Status: CLOSED ERRATA
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Automate (Show other bugs)
5.5.0
Unspecified Unspecified
unspecified Severity low
: GA
: 5.6.1
Assigned To: Patrik Kománek
Milan Falešník
automate
: FutureFeature, Reopened, ZStream
Depends On:
Blocks: 1370488 1371169
  Show dependency treegraph
 
Reported: 2016-03-11 04:37 EST by Peter McGowan
Modified: 2016-08-29 09:23 EDT (History)
12 users (show)

See Also:
Fixed In Version: 5.6.1.2
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-08-26 03:11:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter McGowan 2016-03-11 04:37:52 EST
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
Comment 2 Greg McCullough 2016-03-11 15:27:07 EST
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?
Comment 3 Peter McGowan 2016-03-13 10:40:26 EDT
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?
Comment 4 Greg McCullough 2016-03-16 17:18:32 EDT
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.
Comment 5 Greg McCullough 2016-07-21 17:26:53 EDT
Updated defaults implemented in PR https://github.com/ManageIQ/manageiq/pull/9979

Trello: https://trello.com/c/QxcgpkJf
Comment 8 Greg McCullough 2016-08-01 22:02:31 EDT
Milan - I think this BZ/PR should focus on the changes to Simulate.  We can address the custom button change in a followup PR.
Comment 9 Milan Falešník 2016-08-02 06:58:44 EDT
Verified then.
Comment 11 errata-xmlrpc 2016-08-18 13:44:52 EDT
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
Comment 12 Peter McGowan 2016-08-22 10:07:05 EDT
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

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