Open nastacio opened 4 years ago
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?
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.
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.
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 singleService
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 :Describe the solution you'd like
Istio prescribes the usage of the
app
label to tie variousDeployment
objects to the same logical application inside the service mesh, and the usage of theversion
label to distinguish eachDeployment
version. With all deployments labeled withapp
andversion
labels, Istio then requires a singleService
object with a selector for theapp
label (see above snippet).The AppsodyOperator already allows the addition of the
app
andlabel
versions to theAppsodyApplication
object, so we need a mechanism to achieve that arrangement with a singleService
using a selector matching all theDeployment
objects.As a current workaround, one could ignore the
Service
objects created by the Appsody operator and create their ownService
object with a selector tied to the Istioapp
andversion
labels in the multipleAppsodyApplication
objects representing the multiple versions of the logical application.