Istio "version" label is not supported to allow multiple versions of app in the same cluster

[nastacio]

Feature Request

Deploying multiple versions of the same application in the same cluster is a common practice in order to allow progressive transfer of traffic from the old to the new version over time, for instance, allowing a team to "test in production" with 5% of traffic going to a new release while 95% remains in the older release.

Is your feature request related to a problem?

Yes, for Istio service meshes, which support this concept natively through the usage of the label "version". appsody deploy always removes the old version of an app, there is no option to keep the previous version deployed.

One could try and rename the Appsody application in the app-deploy.yaml, but then Appsody will create two Service objects when what we want is a single Service object with a selector that matches all pods representing all the different versions of the application, such as in the snippet below pulled out of an Istio sample :

apiVersion: v1
kind: Service
metadata:
  name: reviews
  labels:
    app: reviews
    service: reviews
spec:
  ports:
  - port: 9080
    name: http
  selector:
    app: reviews
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: reviews-v1
  labels:
    app: reviews
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: reviews
      version: v1
  template:
    metadata:
      labels:
        app: reviews
        version: v1
    spec:
      serviceAccountName: bookinfo-reviews
      containers:
      - name: reviews
        image: docker.io/istio/examples-bookinfo-reviews-v1:1.15.0
        ports:
        - containerPort: 9080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: reviews-v2
  labels:
    app: reviews
    version: v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: reviews
      version: v2
  template:
    metadata:
      labels:
        app: reviews
        version: v2
    spec:
      serviceAccountName: bookinfo-reviews
      containers:
      - name: reviews
        image: docker.io/istio/examples-bookinfo-reviews-v2:1.15.0
       ports:
        - containerPort: 9080
 ---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: reviews-v3
  labels:
    app: reviews
    version: v3
spec:
  replicas: 1
  selector:
    matchLabels:
      app: reviews
      version: v3
  template:
    metadata:
      labels:
        app: reviews
        version: v3
    spec:
      serviceAccountName: bookinfo-reviews
      containers:
      - name: reviews
        image: docker.io/istio/examples-bookinfo-reviews-v3:1.15.0
        ports:
        - containerPort: 9080

Describe the solution you'd like

Istio prescribes the usage of the app label to tie various Deployment objects to the same logical application inside the service mesh, and the usage of the version label to distinguish each Deployment version. With all deployments labeled with app and version labels, Istio then requires a single Service object with a selector for the app label (see above snippet).

The AppsodyOperator already allows the addition of the app and label versions to the AppsodyApplication object, so we need a mechanism to achieve that arrangement with a single Service using a selector matching all the Deployment objects.

As a current workaround, one could ignore the Service objects created by the Appsody operator and create their own Service object with a selector tied to the Istio app and version labels in the multiple AppsodyApplication objects representing the multiple versions of the logical application.

[arthurdm]

thanks for opening this @nastacio. It seems like this is directly related to the appsody deploy command, in which case it's probably a better fit for the CLI repo?

[nastacio]

thanks for opening this @nastacio. It seems like this is directly related to the appsody deploy command, in which case it's probably a better fit for the CLI repo?

I added more clarification to the issue itself, explaining the reason why this feature needs to be addressed at the operator level: whenever a new version of the application is deployed (same name with the new version field) , the operator creates a new pair of Deployment and Service objects for the new AppsodyApplication object, but Istio prescribes a single Service object for all Deployment objects, using a selector with the Istio app label for all the versions of the application.

[arthurdm]

thanks for the additional info @nastacio

This one is tricky, because we would have multiple AppsodyApplication deployments (creating their Deployment resources) but wanting to share a single Service - the problem is about which deployment owns that Service instance. When we delete an AppsodyApplication we also remove its owned resources, so the Operator would have to be smart enough to pass the ownership to another parent.

We'll need to design this one careful, as we don't yet have any Istio / Service Mesh specific config. I think it's a step forward to have something in that space.

@leochr - I think this one should move to Runtime Component, 0.6.0 or 0.7.0 candidate.