| Page Properties | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
...
Out of scope requirement or feature | Reasoning | Notes |
|---|---|---|
Separate use case environments for user groups or users |
| |
Individually built portal frontend |
|
Open Questions
...
...
Notes
...
...
Question
...
Answer
...
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”?
...
...
Can we use separate xRoads to separate env.?
...
...
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?
...
...
Can the portal be cloud agnostic?
...
looks like this is not achievable currently
...
...
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 Kolevjarkkohyoty
...
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
🎯 Target Audience (Summary of Discussion)
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)
...
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
...
Use Case analysis process / practical country implementation
blocked by Djibouti Analysis until approx.
materialisation of analysis in click through prototype
...
MVP decisions
publicly accessible USCT and Djibouti Use case will run permanently and openly accessible
they will be reset every X hours to a defined default state
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
- update goals and features and afterwards, wireframe current understanding of portal/demo/sandbox Jonas Bergmeier
- define default state for usct (seed data) and research on how to reset to this state over time Oleksii Danyliuk
- how to expose USCT (and later on Djibouti) publicly? jarkkohyoty
- Gitbook subscription expansion vs. other tooling → final check with stakeholders Oleksii Danyliuk
- Gitbook team sync / intro Oleksii Danyliuk
| Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Question | Answer | 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. |
| |
Are we able to provide separate kubernetes clusters? | In general yes. | ||
Can they be forked for separate customers? | Deliverables can be forked:
| ||
Can namespaces be used to separate “customers”? | |||
Can we use separate xRoads to separate env.? | |||
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. |
| ||
What explicit scenarios are there regarding the technical collaboration between a government and Govstack and how can a portal support this? | |||
Can the portal be cloud agnostic? | looks like this is not achievable currently |
| |
How can deployment of products be automated? |
| ||
Git repositories | https://github.com/GovStackWorkingGroup/sandbox-app-portal-backend | ||
Is 'portal' a fitting name? | Could be decided after concept phase |
Scenarios for technical implementation
Oleksii Danyliuk Vasil Kolevjarkkohyoty
Name | Scenario A | Scenario B | Scenario C |
|---|---|---|---|
Description |
|
→ 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 |
|
Benefits | |||
Drawbacks and limitations | |||
Open questions | |||
Conclusion |
→ 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)
- 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
outline draft of portal goals and, if possible, explicit featuresJonas Bergmeier→ postponed due to technical decisions WIP until- decide on goals for running and upcoming sprint and align with stakeholders
- set up follow up for Friday
Action items from
present:
- Oleksii Danyliuk comparison table between scenarios to materialize the Govstack Sandbox infrastructure and on-top assumptions, align with jarkkohyoty and Vasil Kolev
- Vasil Kolev in support of Jonas Bergmeier visualize what’s imagined
- Nico Lueck please review feasibility
- align on portal in context of all (marketing) deliverables in Govstack ecosystem Jonas Bergmeier
...
...
🎯 Target Audience (Summary of Discussion)
|
MVP decisions
publicly accessible USCT and Djibouti Use case will run permanently and openly accessible
they will be reset every X hours to a defined default state
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
- update goals and features and afterwards, wireframe current understanding of portal/demo/sandbox Jonas Bergmeier
- define default state for usct (seed data) and research on how to reset to this state over time Oleksii Danyliuk
- how to expose USCT (and later on Djibouti) publicly? jarkkohyoty
- Gitbook subscription expansion vs. other tooling → final check with stakeholders Oleksii Danyliuk
- Gitbook team sync / intro Oleksii Danyliuk
🏗️ Outline (Summary of Discussion)
|