This PR includes changes to appConfig and onboarding to support adding new application service configs to an existing appConfig when there are provisioned tenants. The new service should be configured and resources provisioned and then each provisioned tenant should be updated to provision and deploy the newly configured service.
This PR does not contain the change to the admin web app to allow updating an existing appConfig with provisioned tenants. For now, to exercise this feature, you must use the Settings Service API to update your appConfig.
Known limitations - adding a new public service with a shorter path prefix that one of the existing services requires all ALB listener rule priorities to be reset prior to the new service being created. Essentially a CloudFormation update-stack has to run for each existing tenant-onboarding-app stack prior to the create-stack call for the new service attempting to set the new ALB listener rule.
There are also sharp edges around deployment of the new service for existing tenants. You have to update the appConfig, wait for the core stack to provision the new ECR repo for the new service, and then docker push your image for the new service. Behind the scenes SaaS Boost will be updating the existing tenant environments and eventually triggering the CodePipeline for the new service. If the container image for the new service hasn't been pushed yet, the deployment will fail.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license
This PR includes changes to appConfig and onboarding to support adding new application service configs to an existing appConfig when there are provisioned tenants. The new service should be configured and resources provisioned and then each provisioned tenant should be updated to provision and deploy the newly configured service.
This PR does not contain the change to the admin web app to allow updating an existing appConfig with provisioned tenants. For now, to exercise this feature, you must use the Settings Service API to update your appConfig.
Known limitations - adding a new public service with a shorter path prefix that one of the existing services requires all ALB listener rule priorities to be reset prior to the new service being created. Essentially a CloudFormation
update-stackhas to run for each existing tenant-onboarding-app stack prior to thecreate-stackcall for the new service attempting to set the new ALB listener rule.There are also sharp edges around deployment of the new service for existing tenants. You have to update the appConfig, wait for the core stack to provision the new ECR repo for the new service, and then docker push your image for the new service. Behind the scenes SaaS Boost will be updating the existing tenant environments and eventually triggering the CodePipeline for the new service. If the container image for the new service hasn't been pushed yet, the deployment will fail.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license