You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 2, 2023. It is now read-only.
While attempting to build a new Appsody application using a Kabanero pipeline, I noticed that all applications end up getting deployed to the same cluster namespace where the pipeline is running, without an option to indicate the desired target namespace for the application.
As a workaround, I see app developers hardcoding the target namespace of a specific cluster into the app-deploy.yaml file of the Appsody application and checking it into the Git repo for the app (see #77) . That means applications must be hardcoded to one specific target deployment, which means applications cannot be reused anywhere else unless the administrators for all target clusters agree on the namespaces for all applications that must be connected to one another and reconfigure all of their specific operators (E.g. Istio) to work on all those namespaces.
In short, requiring applications to hardcode namespaces make them virtually unusable, so we need the pipelines to accept the target namespace as a parameter.
The text was updated successfully, but these errors were encountered:
Our plan is provide a set of deploy pipelines that will work with gitops in the near future. I think that will address the concerns that you have raised.
While attempting to build a new Appsody application using a Kabanero pipeline, I noticed that all applications end up getting deployed to the same cluster namespace where the pipeline is running, without an option to indicate the desired target namespace for the application.
As a workaround, I see app developers hardcoding the target namespace of a specific cluster into the app-deploy.yaml file of the Appsody application and checking it into the Git repo for the app (see #77) . That means applications must be hardcoded to one specific target deployment, which means applications cannot be reused anywhere else unless the administrators for all target clusters agree on the namespaces for all applications that must be connected to one another and reconfigure all of their specific operators (E.g. Istio) to work on all those namespaces.
In short, requiring applications to hardcode namespaces make them virtually unusable, so we need the pipelines to accept the target namespace as a parameter.
The text was updated successfully, but these errors were encountered: