• Rough draft

    • Sandbox deliverables scope

    Owned by Jonas Bergmeier, created
    Last updated: Aug 22, 2023 by Oleksii Danyliuk
    9 min read

    Target release

    Type // to add a target release date

    Epic

    Type /Jira to add Jira epics and issues

    Document status

    DRAFT

     Existing list of objectives

    1. show infrastructure of use case

      1. building blocks

        1. available bb

        2. deployed bb

      2. kubernetes

        1. pots from kubernetes that are deployed

        2. services in the kub pots

    2. manage BBs (single and independent)

      1. show list of available bbs

        1. descriptions, links, etc.

      2. show logs of bbs

      3. deploy bb (bb has responsibility to state availability, sandbox will use their plugin interface to check)

        1. list of active instances of BB

          1. statuses

            1. deploying

            2. deployed

            3. activated

            4. test passed…

            5. error/unknown?

          2. links and info

            1. swagger UI

            2. data management

            3. …

          3. uptime?

          4. resources?

        2. create new instance of BB

      4. stop/shutdown bb ?

    portal for non-technical users

    • show accessible use cases and scenarios

      • show informations and descriptions of use cases

      • show dependencies to BBs and infra

        • show which instances are involved in the use case

      • button to make it live

        • check running BBs

        • use running BBs

      • (challenge with big BBs like mosip because it takes long to deploy, we may be able to use delegates)

      • (we may implement adapters ourselves, because this will be compliance strategy to make non-compliant BBs to comply) —> we will re-check this in 1-2 months

      • (mapping via xroad api after deployment is a challenge)

    unclarities as of 2023-06-22

    • what’s in the cluster? —> we need API to check that, will be checked by Tsveto in next sprint

    • BB have no mandatory interfaces which make them recognizable and make them behave like plugins

      • BBs will be pushed by us to build such plugins

    Existing requirements to review

    #

    Requirement

    Validy as of Aug 1, 2023
    cc @jarkkohyoty @Vasil Kolev @Meelis Zujev (Deactivated) @Nico Lueck

    Feasibility as of Aug 4, 2023 until Dec 22, 2023
    cc @jarkkohyoty @Vasil Kolev @Valentin Filyov @Tsvetomir Krumov

    Comments on Aug 4, 2023

    #

    Requirement

    Validy as of Aug 1, 2023
    cc @jarkkohyoty @Vasil Kolev @Meelis Zujev (Deactivated) @Nico Lueck

    Feasibility as of Aug 4, 2023 until Dec 22, 2023
    cc @jarkkohyoty @Vasil Kolev @Valentin Filyov @Tsvetomir Krumov

    Comments on Aug 4, 2023

    US#1

    HIGH I want to deploy the sandbox with different BB candidates so that I can experience the interchangeability of software components.

    NL: Still valid, but “deploy the sandbox” shouldnt be taken word by word. It is rather “access a use case with different BB candidates”

    • Feasible on individual infrastructure

      • “Infrastructure as a code”

    • Not feasible via public portal

    Community is missing alternative candidates for BBs

    US#2

    HIGH As an IT expert in a Ghanian ministry/contracted IT consultant I want to be able to select for each BB 1 out of 3 Govstack-Compliant applications and deploy them with a particular use-case configuration so that I can understand Govstack interoperability concept and consider using the architecture and methodology in my own digital transformation. (Owner: @Taylor Downs )

    NL: Yes, same as above.

    • Feasible on individual infrastructure

      • “Infrastructure as a code”

    • Not feasible via public portal

    Community is missing alternative candidates for BBs

    US#3

    HIGH I want to test the performance and other metrics (e.g. latency, network speed, response time, compression, carbon footprint) so that I can evaluate the potential usage of the architecture.

    NL: I would lower priority of this point or delete since it is anyhow not reflecting the real performance numbers. What do you think?

    • Not feasible in current infrastructure

    • Might be feasible in other infrastructure (that’s closer to an production environment)

     

    US#4

    HIGH I want to read an up-to-date documentation (technology stack, licenses, architecture diagram,…) so that I can inform myself about details of use software and architecture.

    NL: Valid.

    • feasible

    Sandbox team is documenting sandbox deliverables, community-wide documentation must be orchestrated to be accessible via the Portal

    US#5

    HIGH I want to experience accessibility and UX so that I can assess the usability for my target group.

    NL: Doesnt feel valid anymore. It is rather something for the Online Contruction use case to use the UI Patterns

    • feasible (but out of scope for Sandbox team)

    Link and refer to UX/UI specs

    US#6

    MEDIUM I want to create self-hosted instance of the sandbox so that I can analyze the system in a safe environment

    NL: Valid. Still my assumption that this might be useful. It is what I meant with “replicable vertical prototype”

    TBD

    TBD @Vasil Kolev @jarkkohyoty @Oleksii Danyliuk etc.

    US#7

    MEDIUM I want to be able to access and change source code or any other aspect in a safe environment, so that I can showcase a customized deployment to my colleagues/superiors.

    NL: Valid.

    • feasible

    covered by previous ones (based on working def. how to set up own cluster etc.…)

    US#8

    MEDIUM I want to get a blueprint for DevSecOps environment so that I can build up my own BB-based system.

    NL: Valid. Can also only be done with documentation since it says “blueprint” not “to experience or similar”

    • feasible

    covered by previous ones BUT only referring to documentation level

    US#9

    MEDIUM I want to see the infrastructure performance requirements that is needed to assess the sustainability of the BB based approach.

    NL: I think it is a fair point, but rather for the documentation or a document where we gather learnings from this project.

    • feasible

    metrics of our learnings will be used to document observations

    US#10

    MEDIUM I want to check the administration and maintainability concept so that I can evaluate the potentially needed Maintenace efforts.

    NL: Delete

    TBD with @Nico Lueck @Vasil Kolev

    instead of delete, we should document our observations referring to this user story

    US#11

    LOW I want to save my custom sandbox deployment so that I can continue working with it another time.

    NL: Delete

    TBD with @Nico Lueck @Vasil Kolev

    instead of delete, we should document our observations referring to this user story

    US#12

    LOW I want to change API so that I can test integration with the test environment of my country.

    NL: Possible with the Replicable Vertical Prototype with Emulators? E.g. Exchange an emulator with a software running in my environment

    • feasible

    • Possible via adapters

      • we can document OR

      • create adapter project

    US#13

    LOW I want to get security recommendations on how to set up such an environment so that I can build a secure testing ground for my country's systems.

    NL: Optional

    • feasible

    • Related to devsecops story, should be combined/included

     Goals and requirements MVP

    Touchpoint

    Goal

    General Requirements

    User Story Reference

    Touchpoint

    Goal

    General Requirements

    User Story Reference

    Sandbox Gitbook

    Inform on Sandbox infrastructure

    • Documentation on Sandbox infrastructure

    • (Reference existing documentation from @Akseli Karvinen , @jarkkohyoty , @Vladislav Todorov & @Oleksii Danyliuk )

    [TBC by tech]

    • US#4

    Public Sandbox Demo via Sandbox Gitbook

    Access public demo Sandbox

    • Access up-and-running scenarios

      • Scenarios as a playground (from civil-servant/civil view)

    • Dashboard/monitoring of infrastructure (only for information purposes)

      • Availability of services

      • Next reset of DBs

      • References to Github or resources for used technology

    [TBC by tech]

    • US#4

    Sandbox Gitbook

    Understand service design and implementation process

    • Implementation Playbook reference

    • UX/UI specifications reference

    • Service Design along the implementation playbook - practical example of designing the building permit use case for the Govstack Sandbox along the implementation playbook

      • (Service Prioritization)

      • As is Journey

      • To Be Journey

      • Service Blueprint

      • Requirements and Specifications

      • QA

      • Important differences between sandbox Use Cases and Country implementation process

        • Other part of the implementation playbook which was not considered for generic use cases

        • UI/UX can be different based on the culture, user group/target, legislation, language, existing design system etc which should be considered by each implementation spesificly (For guiding the user UX/UI group work)

          • All the work can be accessible via public figma files (design) and through portal(research and visuals)

    • US#4

    Sandbox Gitbook and DIY

    Take control of and investigate on the Govstack Sandbox

    • Documentation on how to set up own Sandbox

      • Technical requirements and recommendations

      • Security recommendations

      • (Reference existing documentation from @Vladislav Todorov & @Oleksii Danyliuk )

      • Documentation on how to integrate selected BB software

      • Documentation on how to integrate other software

      • Documentation on how to run emulators and adapters

      • How to set up example use cases

        • Technical requirements

        • Deploy scenarios and necessary BBs for them

          • manage BBs (single and independent)

            • show list of available bbs

            • show logs of bbs

            • deploy bb

            • stop/shutdown bb

    [TBC by tech]

    • US#1

    • US#2

    • US#6

    • US#7

    • US#8

    • US#9

    • US#12

    • US#13

     

     Working hypotheses

    @Jonas Bergmeier Aug 10, 2023

    1. It is more valuable to technical consultant if they can access a well structured documentation with the possibility to up-and-run “a Govstack” in their own cloud to investigate upon it, opposed to get somewhat very limited access to a publicly running Govstack infrastructure.

    2. Government decision makers want to see proof that the concept of Govstack works in practice with use cases they can relate to.

    3. Government decision makers are generally more curious about economic factors than technical details, from a certain point onwards technical experts are involved to investigate on details.

    4. It should be convenient and fast to get in touch with experts for government decision makers and technical experts as well.

     Non-functional requirements

    Requirement

    Notes

    Requirement

    Notes

    Mobile first design and full responsive

     

    Maintainability and accessibility of service

     

    Integration of services in existing marketing infrastructure

     

    Accessible via sandbox.govstack.global

     

     Out of Scope

    Out of scope requirement or feature

    Reasoning

    Notes

    Out of scope requirement or feature

    Reasoning

    Notes

    Separate use case environments for user groups or users

    • most options to provide this would massively increase infrastructure costs

    • options that might not increase infrastructure costs massively cause a disproportionate high effort with high complexity

    • relatively low expected users / day based upon govstack.global metrics as of Aug 9, 2023

    • system can reset to default DB state regularly

     

    Individually built portal frontend

    • low sustainability

      • not easily maintainable

      • very high effort to built

      • question of continous maintenance after Sandbox project ends in current form

    • doesn’t help to fulfil the identified requirements compared to using Gitbook

     

    Notes Aug 8, 2023

    Portal scenarios meeting

    MVP decisions

    1. publicly accessible USCT and Djibouti Use case will run permanently and openly accessible

    2. they will be reset every X hours to a defined default state

    3. portal should give possibility to request support for DIY environment (DEV SUPPORT/SERVICE)

    not defined yet: how and where will the deliverables be exposed?

    • depending on the questions:

      • what's the name of it?

      • is the product of the portal self-built, within wordpress or something else, such as gitbook?

    • this will be decided when wireframes are reviewed and scope for mvp is clarified

    Action Items

    Gitbook subscription expansion vs. other tooling → final check with stakeholders @Oleksii Danyliuk
    Gitbook team sync / intro Aug 18, 2023 @Oleksii Danyliuk

     

     Open Questions

    (As of Aug 2, 2023)

    Question

    Answer Aug 9, 2023

    Notes and questions (to answer the question)

    Date Answered

    Question

    Answer Aug 9, 2023

    Notes and questions (to answer the question)

    Date Answered

    How do we provide isolation between the clients?

    The first version of public use case (USCT) wouldn’t include multi tenancy, or client separation logic. System is going to refresh predefined data on schedule base or on demand.
    Currently, the system would not have a client isolation.

    • isolation not extremely important, because this is open information of open source project

    • if we have isolated sandboxes, this is isolated environment anyway

    Are we able to provide separate kubernetes clusters?

    In general yes.

     

     

    Can they be forked for separate customers?

    Deliverables can be forked:

    • paec by

     

     

    Can namespaces be used to separate “customers”?

    @jarkkohyoty

     

     

    Can we use separate xRoads to separate env.?

    @jarkkohyoty

     

     

    How long do we expect users to use the sandbox?

     

     

     

    How do we deploy the different parts of a scenario?

     

     

     

    How to provide access to sandbox?

     

    We already have achievement with cognition/magiclink. Maybe we should continue.

     

    Registration? - Auth etc.

     

    • Barrier of entry should be as low as possible

    • zero installation would be what we want

    •  

     

    What explicit scenarios are there regarding the technical collaboration between a government and Govstack and how can a portal support this?

     

    cc @Nico Lueck @Farina Owusu

     

    Can the portal be cloud agnostic?

    looks like this is not achievable currently

     

    Aug 1, 2023

    How can deployment of products be automated?

     

    • we need automation scripts from vendors

     

    Git repositories

    https://github.com/GovStackWorkingGroup/sandbox-app-portal-backend
    https://github.com/GovStackWorkingGroup/sandbox-app-portal-frontend

     

     

    Is 'portal' a fitting name?

     

    Could be decided after concept phase

     

    Scenarios for technical implementation

    @Oleksii Danyliuk @Vasil Kolev@jarkkohyoty

    Name

    Scenario A

    Scenario B

    Scenario C

    Name

    Scenario A

    Scenario B

    Scenario C

    Description

    • based on architecture WG, we can provide multi-tenant application for the portal with different accounts under this tenant, i.e.

      • government a → tenant

        • user a → user

        • user b → user

        • user c → user

      • government b → tenant

        • user a → user

        • user b → user

        • user c → user

    • make use of API to expose information in portal

    • multi-tenant through different namespaces

    • make use of API to expose information in portal

    • one space / tenant

    • one credential or multiple credentials

    • benefits

      • option to have login inside the cluster

      • provide infrastructure as a code

    • Jarkko: This is only simulating isolation

    → cannot be provided because we can not provide the degree of isolation

    → → → might not be feasible at this stage

    → experimentation

    → retention policy

    → no “raw” access to infrastructure would be given

    • read-only of Govstack infrastructure

    • make use of API to expose information in portal

    • manual assist could be provided to “fork” environment to other environment, Sandbox team or Govstack would provide support with this

    • this should still support possibility to run multiple scenarios in one cluster via namespaces

    Benefits

    @jarkkohyoty @Vasil Kolev @Oleksii Danyliuk

    @jarkkohyoty @Vasil Kolev @Oleksii Danyliuk

    @jarkkohyoty @Vasil Kolev @Oleksii Danyliuk

    Drawbacks and limitations

    @jarkkohyoty @Vasil Kolev @Oleksii Danyliuk

    @jarkkohyoty @Vasil Kolev @Oleksii Danyliuk

    @jarkkohyoty @Vasil Kolev @Oleksii Danyliuk

    Open questions

    @jarkkohyoty @Vasil Kolev @Oleksii Danyliuk

    @jarkkohyoty @Vasil Kolev @Oleksii Danyliuk

    @jarkkohyoty @Vasil Kolev @Oleksii Danyliuk

    Conclusion

    @jarkkohyoty @Vasil Kolev @Oleksii Danyliuk

    @jarkkohyoty @Vasil Kolev @Oleksii Danyliuk

    @jarkkohyoty @Vasil Kolev @Oleksii Danyliuk

    → Conclusion: examination, prototyping and research on scenario B is needed

    Action Items

    review existing user stories from December 2022 @Nico Lueck @jarkkohyoty @Vasil Kolev @Meelis Zujev (Deactivated) Aug 7, 2023
    @Oleksii Danyliuk @Artun Gürkan @jarkkohyoty @Jonas Bergmeier sleep it over and follow-up
    finish architecture scenarios table and decide on next steps and visualize architecture that is decided upon @Oleksii Danyliuk @jarkkohyoty @Vasil Kolev Aug 4, 2023
    outline draft of portal goals and, if possible, explicit features @Jonas Bergmeier Aug 4, 2023 → postponed due to technical decisions WIP until Aug 10, 2023
    decide on goals for running and upcoming sprint and align with stakeholders Aug 7, 2023
    set up follow up for Friday

     

    Action items from Aug 4, 2023

    present:

    @Oleksii Danyliuk comparison table between scenarios to materialize the Govstack Sandbox infrastructure and on-top assumptions, align with @jarkkohyoty and @Vasil Kolev Aug 9, 2023
    @Vasil Kolev in support of @Jonas Bergmeier visualize what’s imagined
    @Nico Lueck please review feasibility Aug 9, 2023
    align on portal in context of all (marketing) deliverables in Govstack ecosystem @Jonas Bergmeier Aug 11, 2023

    Target Audience (Summary of Discussion) Aug 2, 2023

    • Portal must be easily accessible and navigable for different groups with different technical knowledge and experience

    • A specific target group won’t be defined because EVERYONE with genuine interest in Govstack can access the portal in order to understand Govstack from different perspectives

    • Portal should not be in conflict or competition with other govstack dev resources

    • Portal should provide added value from ALL perspectives, such as service design, cloud and infrastructure, resulting use case prototypes, Sandbox, …

    Outline (Summary of Discussion) Aug 2, 2023

    • examination, prototyping and research on if and how to add x+1 namespaces to one cluster and the security-related consequences that come around with this @Oleksii Danyliuk

    • Identification and registration of tenants (client management)

      • what is this needed for?

      • pick up previous work with Magic Link etc.

    • Infrastructure / Dashboard with Kubernetes and xRoad API

    • general iA for the portal @Jonas Bergmeier Aug 14, 2023

    • Use Case analysis process / practical country implementation

      • blocked by Djibouti Analysis until approx. Aug 28, 2023

    • materialisation of analysis in click through prototype

      • provide links to repositories and other resources