Bug 1316842

Summary:	/System/Process/Event should not be displayed as a valid entry point for Automate Simulation
Product:	Red Hat CloudForms Management Engine	Reporter:	Peter McGowan <pmcgowan>
Component:	Automate	Assignee:	Patrik Kománek <pkomanek>
Status:	CLOSED ERRATA	QA Contact:	Milan Falešník <mfalesni>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	5.5.0	CC:	cpelland, gmccullo, hkataria, jhardy, jprause, mkanoor, mpovolny, nachandr, obarenbo, pkomanek, pmcgowan, tfitzger
Target Milestone:	GA	Keywords:	FutureFeature, Reopened, ZStream
Target Release:	5.6.1
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	automate
Fixed In Version:	5.6.1.2	Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-08-26 07:11:46 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1370488, 1371169

Description Peter McGowan 2016-03-11 09:37:52 UTC

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 20:27:07 UTC

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 14:40:26 UTC

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 21:18:32 UTC

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 21:26:53 UTC

Updated defaults implemented in PR https://github.com/ManageIQ/manageiq/pull/9979

Trello: https://trello.com/c/QxcgpkJf

Comment 8 Greg McCullough 2016-08-02 02:02:31 UTC

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 10:58:44 UTC

Verified then.

Comment 11 errata-xmlrpc 2016-08-18 17:44:52 UTC

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 14:07:05 UTC

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