Skip to content
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

Merged
merged 22 commits into from
Jun 27, 2024
Merged

feat: introduce license manager and feature tiers #17396

merged 22 commits into from
Jun 27, 2024

Conversation

BugenZhao
Copy link
Member

@BugenZhao BugenZhao commented Jun 21, 2024

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 or config.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 with Feature::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

  • I have written necessary rustdoc comments
  • I have added necessary unit tests and integration tests
  • All checks passed in ./risedev check (or alias, ./risedev c)

Documentation

  • My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

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.

Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
Copy link
Contributor

@github-actions github-actions bot left a 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

src/common/src/license.rs Outdated Show resolved Hide resolved
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]>
@BugenZhao BugenZhao changed the title feat: introduce license manager and feature tiers feat: introduce license manager and feature tiers [WIP] Jun 24, 2024
@BugenZhao BugenZhao marked this pull request as ready for review June 24, 2024 10:01
@BugenZhao BugenZhao requested a review from a team as a code owner June 24, 2024 10:01
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
Signed-off-by: Bugen Zhao <[email protected]>
@BugenZhao BugenZhao requested review from hzxa21 and fuyufjh June 25, 2024 07:53
@BugenZhao BugenZhao changed the title feat: introduce license manager and feature tiers [WIP] feat: introduce license manager and feature tiers Jun 25, 2024
@fuyufjh fuyufjh requested a review from neverchanje June 25, 2024 08:02
Signed-off-by: Bugen Zhao <[email protected]>
Copy link
Member

@fuyufjh fuyufjh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally LGTM!

src/frontend/src/binder/expr/function.rs Outdated Show resolved Hide resolved
Copy link
Member

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?

Copy link
Member Author

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.

Comment on lines 147 to 148
#[cfg(debug_assertions)]
"test.risingwave.com",
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also related #17456 (comment)

Copy link
Member

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.

Copy link
Member Author

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.

src/license/src/manager.rs Show resolved Hide resolved
src/common/src/system_param/common.rs Outdated Show resolved Hide resolved
src/common/src/system_param/common.rs Show resolved Hide resolved
Copy link
Contributor

@neverchanje neverchanje left a 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.

@BugenZhao BugenZhao added the user-facing-changes Contains changes that are visible to users label Jun 25, 2024
Signed-off-by: Bugen Zhao <[email protected]>
@stdrc stdrc self-requested a review June 26, 2024 02:41
@xxchan xxchan self-requested a review June 26, 2024 03:30
src/common/Cargo.toml Outdated Show resolved Hide resolved
Copy link
Member

@xxchan xxchan left a 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"))
Copy link
Member

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?

Comment on lines 147 to 148
#[cfg(debug_assertions)]
"test.risingwave.com",
Copy link
Member

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.

BugenZhao and others added 2 commits June 26, 2024 15:51
@BugenZhao BugenZhao enabled auto-merge June 27, 2024 03:36
@BugenZhao BugenZhao added this pull request to the merge queue Jun 27, 2024
Merged via the queue into main with commit 855251c Jun 27, 2024
33 checks passed
@BugenZhao BugenZhao deleted the bz/license branch June 27, 2024 04:36
@WanYixian
Copy link
Contributor

WanYixian commented Sep 4, 2024

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

@BugenZhao
Copy link
Member Author

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:

  • before launching a fresh cluster
    • through system.license_key in the TOML configuration
    • through RW_LICENSE_KEY env var
  • after the cluster is initialized, through SQL interface with ALTER SYSTEM SET license_key TO '..' online

@WanYixian
Copy link
Contributor

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:

  • before launching a fresh cluster

    • through system.license_key in the TOML configuration
    • through RW_LICENSE_KEY env var
  • after the cluster is initialized, through SQL interface with ALTER SYSTEM SET license_key TO '..' online

Good to know and I'll add this info into doc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/feature user-facing-changes Contains changes that are visible to users
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants