-
Notifications
You must be signed in to change notification settings - Fork 594
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: introduce license manager and feature tiers #17396
Conversation
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
license-eye has totally checked 5147 files.
Valid | Invalid | Ignored | Fixed |
---|---|---|---|
2198 | 1 | 2948 | 0 |
Click to see the invalid file list
- src/common/src/license.rs
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally LGTM!
src/common/src/license/key.pub
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about storing the private key in a saparated git repo?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still considering the options. One is to store the private key directly in a private repository, while another option is to not expose the key at all but only provide the keygen utility (like a web app) behind some sort of authentication within our organization.
src/common/src/license/manager.rs
Outdated
#[cfg(debug_assertions)] | ||
"test.risingwave.com", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So test.risingwave.com
only works for debug builds. IIUC, the tests using release build (such as the main-cron
and benchmarks) will need to set up a prod.risingwave.com
license to run, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right. We should
- either generate a
prod
key and set them for benchmarks (with potential risk of leaking it) - or use a better compiler flag to distinguish between test/development build and production build, which we don't have now AFAIK
Do you have any preference or other ideas? Also cc @xxchan
BTW, ci-release
profile is used in main-cron
, which enables debug assertions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also related #17456 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or use a better compiler flag to distinguish between test/development build and production build, which we don't have now AFAIK
You reminds me of this: https://github.com/tikv/tikv/blob/master/etc/cargo.config.dist "really prod/dist config" (e.g., fat LTO) vs "release/bench" config. I also wanted a "release without LTO" before, because LTO compiles for too long. 🤣
Anyway, I feel generate a prod
key for benchmark is enough. And we can manage it in test env like AWS secrets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You reminds me of this: tikv/tikv@
master
/etc/cargo.config.dist "really prod/dist config" (e.g., fat LTO) vs "release/bench" config. I also wanted a "release without LTO" before, because LTO compiles for too long. 🤣
True. The problem is that we don't currently distinguish between production and bench builds. So we have to either refactor the benchmark pipeline to use another set of images, or provide runtime functionality to switch between them, which is certainly unsafe.
Anyway, I feel generate a
prod
key for benchmark is enough.
Okay.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The user interface LGTM.
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
} | ||
|
||
static PUBLIC_KEY: LazyLock<DecodingKey> = LazyLock::new(|| { | ||
DecodingKey::from_rsa_pem(include_bytes!("key.pub")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Can we inline the file key.pub
?
src/common/src/license/manager.rs
Outdated
#[cfg(debug_assertions)] | ||
"test.risingwave.com", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or use a better compiler flag to distinguish between test/development build and production build, which we don't have now AFAIK
You reminds me of this: https://github.com/tikv/tikv/blob/master/etc/cargo.config.dist "really prod/dist config" (e.g., fat LTO) vs "release/bench" config. I also wanted a "release without LTO" before, because LTO compiles for too long. 🤣
Anyway, I feel generate a prod
key for benchmark is enough. And we can manage it in test env like AWS secrets.
Co-authored-by: xxchan <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
Hi @BugenZhao, wanna a double check, on the very-first startup of the cluster, would there be a prompt to remind user to specify the license file location? Thanks |
No. Also it's not to provide a license file. Users can specify the license key content in following ways:
|
Good to know and I'll add this info into doc |
Signed-off-by: Bugen Zhao [email protected]I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
Introduce
LicenseManager
and feature tiers roughly based on the design in the doc.A license key is a JWT (JSON Web Token) encoding information like tier and expiration time, of which the integrity can be validated with asymmetric encryption.
The license key is made a system parameter, which can be set through
ALTER SYSTEM SET license_key TO ..
in runtime orconfig.toml
on the very-first startup of the cluster. Whenever the key is changed, it'll be propagated to all components in the cluster and get refreshed. The reason for not making it something static (like env var) is due to concerns on expiration of the license key. By allowing it to be updated online, users don't have to suspend the service when renewing the license.Certain enterprise features may be restricted to specific tiers. This can be done by adding a new entry to the macro
for_all_features
, then check it during runtime withFeature::Foo.check_available()?
. Complete guidelines are included in the source file as documentation.To simplify testing, a license key with tier
Paid
is set by default in debug mode, so that all features should be available without any other configuration. This is okay because the issuer in the key specifies that the key is for testing purposes only and will be rejected in production.The test case
error_ui/simple/license.slt
shows the behavior when a paid feature is called under different circumstances.Checklist
./risedev check
(or alias,./risedev c
)Documentation
This PR introduces a new system parameter of
license_key
that can be set to enable some enterprise features in the future.Besides, this PR introduces a new SQL function
SELECT rw_test_paid_tier();
that checks whether the current deployment has the paid tier access. Please refer users to the enterprise feature tier document for details. If the user is using a valid license key, the result will be 't' (true). Otherwise, this function will return an error.Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.