docs: add Ratify v2 design scope discussion #1905
Conversation
binbin-li
requested review from
akashsinghal,
jimmyraywv,
luisdlp,
susanshi and
toddysm
as code owners
Codecov ReportAll modified and coverable lines are covered by tests ✅ |
binbin-li
force-pushed
the
ratify-v2
branch
2 times, most recently
from
92bea57
to
1fdad75
Compare
|
|
||
| ### New Features | ||
|
|
||
| The v2 design mainly focuses on the fundamental refactoring and deprecations that are necessary for the system. In our first prototype or first RC/official release, we may not have new features. However, we should keep the following features in mind to avoid introducing new limitations or breaking changes in the future. |
There was a problem hiding this comment.
Looking at the whole proposal, it seems primarily focus on the refactoring and deprecation but less on new features. The title seems like look ahead a BIG plan of a new major milestone (v2) but without such detailed context as refactoring and deprecation.
How about focusing on the refactoring and deprecation only, moving the feature planning to the ROADMAP.md? It would be good to add concrete plans for the whole v2 with each minor milestone (v2.x) in a central roadmap doc, which also requires further discussion and alignment.
There was a problem hiding this comment.
Thereby, I am thinking this title "Proposal: A more lightweight and extensible framework for Ratify v2".
Deprecation and reducing dependencies make Ratify more lightweight and refactoring is intended for evolving to be a more maintainable and extensible framework.
There was a problem hiding this comment.
Good call, my initial idea to add the new feature section is to remind me of those features while refactoring. I would remove it if more reviewers agree on it. And I can also just add link to our roadmap if necessary.
There was a problem hiding this comment.
Per the community meeting discussion on Nov 13, Ratify maintainers agreed to move the New Features section to the ROADMAP.md.
Signed-off-by: Binbin Li <[email protected]>
| 1. Deprecate outdated features so that customers can have a clear understanding of the features that are still supported. | ||
| 2. Refactor the code to make it more maintainable and extensible for new features. | ||
| 3. Improve the performance of the system. | ||
| 4. Improve the usability of the system. |
There was a problem hiding this comment.
Have we considered adding new primitives that wrap/simplify the other components. (e.g introduce a new CRD that synthesizes store + verifier + policy). This is similar to the simplification proposed by @yizha1 so that user is only concerned with a single CRD.
There was a problem hiding this comment.
yeah, that's good call. I agree that would enhance user experience, but don't have clear idea on it yet. Just wrapping everything up may not be a good solution. And I'm also considering deprecating wrapped CRDs by this new CRD. May need more feedback from @yizha1 as we have discussed it before.
| 2. Refactor the code to make it more maintainable and extensible for new features. | ||
| 3. Improve the performance of the system. | ||
| 4. Improve the usability of the system. | ||
| 5. Reduce the dependencies of the system. |
There was a problem hiding this comment.
+1. This is also becoming a large problem for built-in functionality. Cloud provider specific packages + cosign + notation mean we have a very large # of dependencies imported. Vulnerability and version management has become tricky. Case and point is the volume of dependabot PRs we deal with weekly. Curious to hear any thoughts you have on how we can streamline.
|
|
||
| ## Scope | ||
|
|
||
| Overall, the scope of the v2 design includes the following aspects: system refactoring, deprecations, new features, document update and unit test improvement. We'll discuss each aspect in detail. |
There was a problem hiding this comment.
How about attestation support that is coming up on the horizon? Attestations are tricky in that they are synthetic bundle of signatures, envelope, and a verifiable artifact. This may introduce a new first class component in Ratify. Would this be out of scope for v2.0.0?
There was a problem hiding this comment.
good call! That should be considered in v2.0.0 but will be low prioritized. I feel the problem is that we don't have a clear design for attestation support yet. Basically the v2 prototype should be easy for us to support it without breaking change.
| 2. Oras store only supports one auth provider. One of the reasons is that the Oras store configuration does not support multiple auth providers. Related issue: [issue-974](https://github.com/ratify-project/ratify/issues/974). | ||
|
|
||
| **Proposed Solution**: | ||
| 1. Update the CLI configuration format to be forward-compatible with missing features. |
There was a problem hiding this comment.
I would recommend we remove all of the extra non-essential commands in the CLI today. Even the primary verify command will need a large overhaul to provide a better configuration experience. Given the complexity of the config file, I think we need a way for user's to compose the config file from the command flags itself.
There was a problem hiding this comment.
I agree. And we don't have much unit tests for CLI, I think it's a good opportunity for us to redesign the CLI commands (deprecate unused ones and add new ones).
| 2. Oras store only supports one auth provider. One of the reasons is that the Oras store configuration does not support multiple auth providers. Related issue: [issue-974](https://github.com/ratify-project/ratify/issues/974). | ||
|
|
||
| **Proposed Solution**: | ||
| 1. Update the CLI configuration format to be forward-compatible with missing features. |
There was a problem hiding this comment.
I think we also need to reconsider the purpose of the CLI and how it's been used. Ideally, we want user's to be able to use the ratify cli as a standalone tool in their CI/CD pipeline. However, currently, I've heard feedback from folks saying they use the CLI almost as a test bed check to understand and validate what the output of Ratify will be for an image before setting up Ratify on the cluster with a config. If we can help make that configuration workflow transfer more easily between CLI and cluster, it could be valuable. Just some unverified thoughts I have so far :)
|
posting notes from community meeting discussion here so we don't lose it:
|
Signed-off-by: Binbin Li <[email protected]>
Description
What this PR does / why we need it:
Add docs for Ratify v2 design scope discussion
Which issue(s) this PR fixes (optional, using
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when the PR gets merged):Fixes #1885
Type of change
Please delete options that are not relevant.
mainbranch)How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Please also list any relevant details for your test configuration
Checklist:
Post Merge Requirements
Helm Chart Change