Merge pull request #1257 from threefoldtech/development_add_storing_a…

…rch_decision

Add deployments store path arch decision

packages/grid_client/docs/architecture/decisions/support_hex_based_seed.md

@@ -0,0 +1,25 @@
+# 3. support_hex_based_seed.md
+
+Date: 2023-11-16
+
+## Status
+
+Done
+
+## Context
+
+Add support for hex based seed (Aka. hexSeed). Basically it's an algorithm derive a hexSeed from regular mnemonic which can be used while interacting with chain without exposing user's mnemonic.
+
+Note: Threefold Connector App is using hex based seed so now users can copy their hexSeed and use it directly in our clients
+
+## Decision
+
+Currently, We added a `toHexSeed` helper to convert any passed mnemonic into hexSeed and if the user passed hexSeed it stays as it is.
+
+Example:
+mnemonic: "word position fox tonight initial genuine liquid jewel almost craft broom maximum"
+hexSeed: "0xd8c3909af2227220a5ad15cc5fe1aeb8bd620b50b96d910220c2062c18b28232"
+
+## Consequences
+
+There is no specific consequences related.

packages/grid_client/docs/architecture/decisions/update_deployments_store_path.md

@@ -0,0 +1,21 @@
+# 2. update_deployment_store_path
+
+Date: 2023-10-22
+
+## Status
+
+Done
+
+## Context
+
+Previously we had no way to group folders so we decided to allow combining related contracts as a folder structure can be used in different project (e.g playground).
+
+## Decision
+
+- We are migrating old key to a new one which allows us to combine related contracts together as a folder grouping.
+- Pattern: `[network]/[twinId]/[projectName]/[moduleName]/[instanceName]/contracts.json` to `[network]/[twinId]/[moduleName]/[projectName]/[instanceName]/contracts.json`
+- Example: `dev/370/vm/machines/testvm/contracts.json` to `dev/370/machines/vm/testvm/contracts.json`
+
+## Consequences
+
+There is no specific consequences related.

packages/playground/docs/decisions/update_deployments_store_path.md

@@ -0,0 +1,47 @@
+# 1. update_deployment_store_path
+
+Date: 2023-10-22
+
+## Status
+
+Done
+
+## Context
+
+Previously we didn't have a way to tell that a gateway is related to a certain virtual machine. So we decided to make some updates will be listed below in order to be able to group all deployments' workloads in a similar path hierarchy.
+
+e.g
+
+```bash
+tfchain
+  |_ tfkvstore
+    |_ machines
+    | |_ vm # projectName
+    |    |_ testvm # instanceName
+    |      |_ testvm
+    |          |_ contracts.json
+    |_ gateways
+       |_ vm # projectName
+         |_ testvm # instanceName
+           |_ testvmGateway
+              |_ contracts.json
+```
+
+## Decision
+
+1. For old deployments
+
+   - We added a migration script will be applied whenever the user tries to list his own deployments
+   - Migrated deployments will be getting an update in their contracts' data (if needed)
+   - Migrating the contracts is done by only one request to update the contract.
+   - Keys stored on the kvstore on tfchain are migrated by creating a new key and removing the old one.
+
+2. For new deployments
+   - The projectName has been updated to match the new pattern for the deployment. For example, if the deployment is called `testvm` in the projectName called `vm` the new projectName will be `vm/testvm` instead of `vm`.
+   - Gateways will be stored in the same previous projectName pattern mentioned above.
+   - Listing will follow the same pattern. After listing all deployments related to a specific projectName (e.g `p1`) let's say we got deployments `[d1, d2]` so we will load the deployment of `d1` from the projectName `p1/d1` and the deployment `d2` is the same in the playground.
+   - For Kubernetes, it doesn't use any projectName so the projectName will be the instanceName itself.
+
+## Consequences
+
+There is no specific consequences related.