July 11, 2023 - Alignment Meeting # 13

Discussion on new proposed approach of Sandbox environment and deployment of BB implementations into the Sandbox

• The Sandbox team was asked to present the new strategy for creating isolated environments for building block providers.

• The Sandbox team proposed the idea to have separate accounts for each building block vendor, providing an equivalent sandbox environment. These accounts would have admin and access rights for the vendor company to install their software into the designated location.

• Discussed the challenges faced in deploying applications in the sandbox, requiring extensive communication and knowledge acquisition for each building block. This poses limitations of scaling the Sandbox team to handle the increasing number of building blocks.

• Emphasized the need to minimize resource requirements in the sandbox and provide dedicated locations for each vendor to install their software. This would involve assessing software dependencies, infrastructure requirements, and optimizing installations.

• The proposed approach involved vendors minimizing their installations and packaging the software according to specified requirements. The packaged versions would be versioned and moved into the internal repository for deployment in the sandbox.

• The Sandbox team proposed a common playground environment where all building blocks would be installed and tested to ensure compatibility with each other. This step aimed to validate successful deployment and pre-configuration of software from any vendor.

• Highlighted need for administrative access for certain configurations which couldn't be accommodated in the common playground. The separate environments would enable building blocks to be installed with administrative access, ensuring successful deployment.

• Need for a sense of urgency regarding the timeline. The plan is to provide separate playground environments as soon as possible, starting with one BB partner and then continuing with others.

• Concerns were raised about the inability to create persistent volumes in the existing tiered or multi-tenant system. Emphasized the importance of finding a solution that was not cloud-dependent.

• Technoforte and MIFOS teams expressed being blocked due to various issues. The need for immediate resolution and deployment of the environment was stressed. It was agreed upon to address the issues through direct communication and collaboration.

• Concerns about resource allocation and deployment plans, given the delays in accessing the new environment. Need for clarity on timelines and access to the Sandbox environment to assess the impact on plans and resourcing.

• Need for an ongoing internal handover process and configuration setup for the new environment. Need to resolve certain configurations and ensure only one organization was dealing with hosting solutions.

• It was clarified that the deployment of the separate environments would occur sequentially over a few days, allowing each building block to adapt their installations and configurations. However, existing deployments in the sandbox could continue using previous procedures.

• Specific technical issues for deployment were discussed that included topics such as persistent volumes, EC2, VPC, subnets, DNS configuration, and external communication dependencies.

• Need for proper documentation to facilitate understanding and implementation. The Sandbox has been requested for clear documentation on the deployment plan, including steps, specific requirements, and considerations for persistent volumes.

• The team clarified that the documentation was currently a work in progress, as the environment setup and requirements were still being collected and refined. The aim was to gather feedback from BB partners and create a consistent, cloud-agnostic approach.

Discussion on USCT use case application and integration between the application, building blocks, and web server.

• Discussion on the scope of the sandbox and demo environment, including the application, building blocks, and web server.

• Communication and integration between different components were discussed, along with the need for access control and authorization management.

• The current scope involves one application (USCT application) within the sandbox, which serves as the front end and handles the UI for the building blocks. The building blocks do not have their own UI and communicate with the application through the back end.

• Communication between the application and the building blocks is facilitated through internal DNS and information mediator. Public APIs are used for front-end access, and security measures are in place.

• ID BB and access control implementation planned for the next sprint. The aim is to provide a common solution for authentication and authorization.

• Discussed the need for egress calls from building blocks to external applications, such as payment gateways. It is expected that such egress calls will be part of the full use case demonstration.

• Discussed the availability and accessibility of administrative interfaces for the building blocks. There is a debate about the priority and necessity of these interfaces in the sandbox environment.

• Discussed the role of web servers, the need for separate UIs for each building block, and the integration of different back ends into a single web server.

• The importance of a clear deployment procedure and a ready environment for BB partners to try out was emphasized. There is a need to address any blockers related to administrative rights and resource availability.

• The goal is to provide convenience, better visibility, and assessment for BB partners to showcase their building blocks and functionalities. The new environment is aimed at facilitating collaboration, assessing dependencies, and achieving compliance with GovStack’s requirements.

1. Sandbox environment creation and deployment of BB implementations in isolated environments

@Vasil Kolev @Karthik SJ @David Higgins @Allan Bernard