Goal: Users new to a service mesh will likely have limited knowledge/expertise in the domain specific language (DSL) used by Istio as well as by Kubernetes. So as to increase the adoption and usability of Red Hat OpenShift Service Mesh (OSM) we want users to execute common configuration needs/patterns through a web interface.

Across the various stages, the goal is to ensure every major feature of the service mesh can be configured completely from a browser. This does not mean that all features need to have parity or even equal ease of use.

MVP: We provide a GUI for doing A/B traffic balancing between two versions of a service. (Possibly having a slider between two versions).
Advanced: We identify the the top five features and provide an in browser workflow aiding the user the feature’s configuration (e.g. for configuring traffic routing we query and return the list of “subsets” as a drop down and ensure all weights add up to 100%).
Suggestions:
Traffic Routing
Path based routing configuration
Header based routing
Response code routing
Canary Release

Ideal: Users can configure any/all features via a web browser via a guided workflow (without using a YAML editor).

Problem: The configuration of OpenShift Service Mesh currently requires the use of multiple command line tools (oc and istioctl at a minimum). As these tools are both operating system specific and not guaranteed to be available on a user’s workstation it requires the installation of software which places additional burden on the user.

Today when editing resources using a YAML editor within the OpenShift console it’s easy to run into race conditions. If a service is unhealthy or multiple users are mutating a resource, it can be challenging to make the needed change in the time required.

Why is this important: It has been called out internally that the vision for cloud-native app development is “... to simplify the creation of cloud-native services and serverless functions with a rich set of components and tools without forcing a deep knowledge of Kubernetes.”

When juxtaposed with the view that over 20% of a user’s time is spent just building and maintaining development environments, we need to reduce the complexity and tooling required for users to get started.

Dependencies (internal and external):

Prioritized epics + deliverables (in scope / not in scope):

In scope:

Out of scope:

Estimate (XS, S, M, L, XL, XXL): M (For MVP)

Previous Work:
VAMP from Magnetic IO - https://github.com/magneticio/vamp2setup#performing-a-canary-release
3Scale has invested some effort into visualized guidance around configuration. 3Scale has shared a bunch of information about their feature map in this presentation.
One important idea is noting some of the guidance provided around configuration, e.g. URL re-writing:
(Slide 72, other visualizations ~slide 67 - 80)

Customers:

Open questions:

What are the top three configuration routines users need to execute?
Are there specific changes istio may need to make to improve validation hooks so that Kiali can use this?
Presently with Galley this operates solely on a single object level, allowing Kiali to provide more value to end users by providing a higher level of validation?
Is there a way to consume some of the mechanisms/workflows from 3Scale?