Usability: Pipeline editor: "legacy" runtime images are not displayed

1.3-dev

• Clone the Elyra examples repository https://github.com/elyra-ai/examples.git

• Navigate to pipelines/dax_noaa_weather_data

• Open the pre-configured pipeline. It was created using Elyra 1.2.x

• Hover over a node. Note the associated runtime image

  

• Open the properties of the selected node. Note that the selected runtime image drop-down is empty

  

It appears that this will always happen when Elyra is re-installed and new runtime image versions are included. In my case the pipeline was created using pandas 1.0.3 whereas 1.3-dev includes only a definition for pandas 1.1.1.

While the behavior is expected from an implementation point of view it is confusing to a user because there are now two scenarios for which the entry is empty.

• A user never assigned a runtime image to a node (leads to validation error)
• A user assigned a runtime image to a node but the runtime image configuration is no longer present (no validation error)

Should the selected drop down entry maybe show a placeholder that indicates that no runtime image configuration is associated with the selected value to distinguish the two?

[kevin-bates]

The issue Patrick is raising is that the ‘edit properties’ dialog doesn’t show the image name when the image name has become detached from its original runtime-image instance. This results in an ambiguity between nodes that have no image selected and those that have a “detached” image selected.

Since we already show the runtime-image instance name when there is a match with a runtime-image instance (and I wasn’t aware of that “matching” functionality until now), it seems like we should simply show the image name when no match to a runtime-image can be found. Not sure if there should be an indication, in this case, that the image name is not associated with any runtime-image instance, but that would disambiguate the two scenarios.

[kevin-bates]

I don’t understand your response. Why should the user have to change the image that works perfectly well (otherwise they’d change the image)? The issue is that when there’s no match (which is out of control), we don’t seed the dialog with the image name that is in use. That is misleading.

Just because we don’t have control over the match/display, we do have control over the set to match from. So it seems we could fabricate “virtual” runtime-image entries that map ‘image name’ to ‘image name’ rather than ‘image name’ to ‘runtime-image instance name’ in cases where the configured image name that exists in the pipeline is now NOT in the list of runtime-image instances.

Displaying blank for something that is not blank is a bug.