stratis-storage / stratisd

Easy to use local storage management for Linux.
https://stratis-storage.github.io
Mozilla Public License 2.0
793 stars 56 forks source link

Metadata rework #3637

Closed jbaublitz closed 1 month ago

jbaublitz commented 2 months ago

Follow up on #3274

mulkieran commented 1 month ago

@jbaublitz Plz rebase and resolve conflicts.

jbaublitz commented 1 month ago

/packit test

mulkieran commented 1 month ago

Please go ahead and extend the TMT-based udev and bind tests for v2 pools. https://github.com/stratis-storage/stratisd/pull/3643 is an indication of how to do that. The actual test changes are not at all considerable, feel free to choose something else if you want.

jbaublitz commented 1 month ago

In pool-level metadata, "features" is double-nested. Here is an excerpt from the metadata print out.

  "features": {
    "features": [
      "Encryption"
    ]
  },

This is not a bug, but rather the result of the default behavior for serde derive. We chose to wrap the features in a new-type struct which is resulting in the double nesting. To change the behavior you're seeing if it's important to you, I think we could either replace the new-type struct with a Vector in the metadata or we could rename one of the keys.

mulkieran commented 1 month ago

In pool-level metadata, "features" is double-nested. Here is an excerpt from the metadata print out.

  "features": {
    "features": [
      "Encryption"
    ]
  },

This is not a bug, but rather the result of the default behavior for serde derive. We chose to wrap the features in a new-type struct which is resulting in the double nesting. To change the behavior you're seeing if it's important to you, I think we could either replace the new-type struct with a Vector in the metadata or we could rename one of the keys.

It is certainly a consequence of the default behavior for serde_derive and it works perfectly correctly within stratisd. The reason I noticed it at all was while writing tests external to stratisd that verify invariants that should hold for the metadata. The question is, is it the metadata structure we want to support or would we prefer to avoid that apparently redundant key?

jbaublitz commented 1 month ago

In pool-level metadata, "features" is double-nested. Here is an excerpt from the metadata print out.

  "features": {
    "features": [
      "Encryption"
    ]
  },

This is not a bug, but rather the result of the default behavior for serde derive. We chose to wrap the features in a new-type struct which is resulting in the double nesting. To change the behavior you're seeing if it's important to you, I think we could either replace the new-type struct with a Vector in the metadata or we could rename one of the keys.

It is certainly a consequence of the default behavior for serde_derive and it works perfectly correctly within stratisd. The reason I noticed it at all was while writing tests external to stratisd that verify invariants that should hold for the metadata. The question is, is it the metadata structure we want to support or would we prefer to avoid that apparently redundant key?

I've removed the redundant key.

jbaublitz commented 1 month ago

I'm going to try rerunning the tests here. I've been unable to reproduce the failures I'm seeing locally in a VM with the same code.

jbaublitz commented 1 month ago

/packit test

jbaublitz commented 1 month ago

I think this might be a timing issue which is why I can't reproduce it locally. Last time rawhide succeeded.