Skip to content

feat(storage): add index to schema#1748

Closed
joseivanlopez wants to merge 11 commits intoagama-project:storage-config-uifrom
joseivanlopez:storage-schema-index
Closed

feat(storage): add index to schema#1748
joseivanlopez wants to merge 11 commits intoagama-project:storage-config-uifrom
joseivanlopez:storage-schema-index

Conversation

@joseivanlopez
Copy link
Contributor

@joseivanlopez joseivanlopez commented Nov 12, 2024

Changes:

  • Calculate initial proposal from a JSON config generated from the product data.
  • Add index to the storage schema: it allows to detect which unsolved config correspond to each drive and/or partition. Changing a config (e.g., the size of a partition) will be easier thanks to the index too.
  • Improve model to add information about auto sizes.
  • Improve model to add information about resized partitions.

@coveralls
Copy link

coveralls commented Nov 12, 2024

Pull Request Test Coverage Report for Build 11800402213

Details

  • 43 of 43 (100.0%) changed or added relevant lines in 14 files are covered.
  • 2 unchanged lines in 1 file lost coverage.
  • Overall coverage remained the same at 71.449%

Files with Coverage Reduction New Missed Lines %
service/lib/agama/storage/config_conversions/to_json_conversions/volume_group.rb 2 89.66%
Totals Coverage Status
Change from base Build 11781949244: 0.0%
Covered Lines: 16937
Relevant Lines: 23705

💛 - Coveralls

@joseivanlopez joseivanlopez force-pushed the storage-schema-index branch 2 times, most recently from e8aa831 to 75484a9 Compare November 13, 2024 13:14
@joseivanlopez joseivanlopez marked this pull request as ready for review November 13, 2024 14:42
@ancorgs
Copy link
Contributor

ancorgs commented Nov 13, 2024

I'm just starting, but I admit I didn't expect to see the indexes on the schema. Feels like leaking an internal implementation detail.

@joseivanlopez
Copy link
Contributor Author

After some discussions, we decided to move the config model to the backend. It is easier to implement without the need of adding any artificial properties to the config schema (like the index). Moreover, other clients (e.g., a TUI) could get benefit of the model too.

Closing in favor of #1763.

joseivanlopez added a commit that referenced this pull request Nov 26, 2024
A config model is an abstraction of the storage config to make easier
for clients to deal with the storage config. Clients (e.g., the web UI)
do not need to understand the complexity of the storage config. Instead
of that, clients directly work with the config model for both reading
the config and applying changes.

Example of storage config:

~~~
{ 
  "drives": [
    {
      "search": {
        "condition": { "name": "/dev/vda" },
        "max": 1,
        "ifNotFound": "error"
      },
      "partitions": [
        { "search": "*", "delete": true },
        { "generate": "default" }
      ]
    }
  ]
}
~~~

And its equivalence in the config model:

~~~
{
  "drives": [
    {
      "name": "/dev/vda",
      "spacePolicy": "delete",
      "partitions": [
        { "name": "/dev/vda1", "delete": true },
        { "name": "/dev/vda2", "delete": true },
        {
          "mountPath": "/",
          "filesystem": {
            "default": true,
            "type": "btrfs",
            "snapshots": false
          },
          "size": {
            "default": true,
            "min": 2048
          }
        }
      ]
    }
  ]
}
~~~

Note: this PR replaces #1748
in which the model was implemented in the web side.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants