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: enterprise edition #1575

Merged
merged 50 commits into from
Oct 6, 2022
Merged

feat: enterprise edition #1575

merged 50 commits into from
Oct 6, 2022

Conversation

mindhash
Copy link
Contributor

This PR introduces:

  • feature flagging
  • EE code separation
  • licensing (for EE)
  • SAML SSO (for EE)

@mindhash mindhash requested a review from ankitnayan September 16, 2022 09:47
@mindhash mindhash marked this pull request as ready for review October 1, 2022 17:06
ee/query-service/app/api/api.go Show resolved Hide resolved
ee/query-service/app/api/api.go Show resolved Hide resolved
ee/query-service/app/api/api.go Show resolved Hide resolved
ee/query-service/app/api/api.go Show resolved Hide resolved
ee/query-service/app/api/auth.go Show resolved Hide resolved
Signed-off-by: Prashant Shahi <prashant@signoz.io>
Signed-off-by: Prashant Shahi <prashant@signoz.io>
Signed-off-by: Prashant Shahi <prashant@signoz.io>
Signed-off-by: Prashant Shahi <prashant@signoz.io>
ee/query-service/app/api/api.go Show resolved Hide resolved
ee/query-service/app/api/api.go Show resolved Hide resolved
ee/query-service/app/api/auth.go Show resolved Hide resolved
ee/query-service/app/db/reader.go Show resolved Hide resolved
Signed-off-by: Prashant Shahi <prashant@signoz.io>
@@ -22,4 +22,4 @@ rule_files:
scrape_configs: []

remote_read:
- url: tcp://localhost:9000/?database=signoz_metrics
- url: tcp://stagingapp.signoz.io:9000/?database=signoz_metrics
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
- url: tcp://stagingapp.signoz.io:9000/?database=signoz_metrics
- url: tcp://localhost:9000/?database=signoz_metrics

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I will remove this file from PR.

pkg/query-service/auth/auth.go Show resolved Hide resolved
pkg/query-service/auth/auth.go Show resolved Hide resolved
pkg/query-service/auth/auth.go Show resolved Hide resolved
pkg/query-service/auth/auth.go Show resolved Hide resolved
Comment on lines +14 to +18
type ErrEmailRequired struct{}

func (errEmailRequired ErrEmailRequired) Error() string {
return "email is required"
}
Copy link
Member

Choose a reason for hiding this comment

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

I understand the intent behind this but there is no data associated with these error types. What do you think about defining them with errors.New/fmt.Errorf?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think we should adopt named error codes as a pattern. This will help with a centralised control on error messages. especially if we consider applying translations (internationalisation) in future.

Most well-known libraries take a named errors approach as well. e.g. AWS sdk

The error structs can evolve contain into internal message (to be written to log) for developers and the error message to be displayed to the end user. At the moment, we just show 'something went wrong'. Printing internal error on web console (developer console) will help with additional context. Having requestId will also help.

In this PR, I could not make all changes at once but wanted to initiate this change atleast for generic and common errors.

Copy link
Member

Choose a reason for hiding this comment

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

I generally find them to be useful and think same pattern doesn't fit well with all types of errors. I think the question boils down what should be named error? For example the os package defines several error with errors.New where the error is simply a message https://github.com/golang/go/blob/efa357ce3c1a8ef0ce94347fef533c87673a598a/src/os/error.go#L16-L24 which are basically taken from here https://github.com/golang/go/blob/2ebe77a2fda1ee9ff6fd9a3e08933ad1ebaea039/src/internal/oserror/errors.go. If there is additional functionality we can't achieve with them then it makes sense to go with named errors.

I find this is more concise.

var (
	ErrEmailRequired    = errors.New("email is required")
	ErrPasswordRequired = errors.New("password is required")
	ErrSignupFailed     = errors.New("failed to register user")
	ErrNoOrgFound       = errors.New("no org found")
)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I am going to skip this for now. We can discuss more, as I will log a separate issue for named errors. I think if we are looking translations (internationalisation) a struct enables adding language code. Usually language code will come from the current user.

The front-end already takes care of majority of translations but doesn't have control over the error messages.

e.g.
ErrEmailRequired {
Lang: string;
}

func (e *ErrEmailRequired) Error() string {
case e.Lang {
case English.US:
return 'Email is required''
Case Spanish:
....
}

pkg/query-service/auth/auth.go Show resolved Hide resolved
pkg/query-service/auth/auth.go Show resolved Hide resolved
ee/query-service/saml/request.go Show resolved Hide resolved
Comment on lines +7 to +21
type ApiError struct {
Typ basemodel.ErrorType
Err error
}

func (a *ApiError) Type() basemodel.ErrorType {
return a.Typ
}

func (a *ApiError) ToError() error {
if a != nil {
return a.Err
}
return a.Err
}
Copy link
Member

Choose a reason for hiding this comment

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

Is this required? I see they are no different from the base model. Do you think these definitions will evolve to be different for ee? I doubt it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I wanted to reduce references to base code (non-ee) in ee code.

Ideally the BaseApiError(Interface) should be used on both sides passing errors between methods . both EE and OSS can have their own implementations. I couldn't make this change in base (oss) as I wanted to limit the changes in base in this PR.

EE error reporting can evolve differently especially features like sending error reports etc can come in.

Comment on lines +14 to +18
type ErrEmailRequired struct{}

func (errEmailRequired ErrEmailRequired) Error() string {
return "email is required"
}
Copy link
Member

Choose a reason for hiding this comment

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

I generally find them to be useful and think same pattern doesn't fit well with all types of errors. I think the question boils down what should be named error? For example the os package defines several error with errors.New where the error is simply a message https://github.com/golang/go/blob/efa357ce3c1a8ef0ce94347fef533c87673a598a/src/os/error.go#L16-L24 which are basically taken from here https://github.com/golang/go/blob/2ebe77a2fda1ee9ff6fd9a3e08933ad1ebaea039/src/internal/oserror/errors.go. If there is additional functionality we can't achieve with them then it makes sense to go with named errors.

I find this is more concise.

var (
	ErrEmailRequired    = errors.New("email is required")
	ErrPasswordRequired = errors.New("password is required")
	ErrSignupFailed     = errors.New("failed to register user")
	ErrNoOrgFound       = errors.New("no org found")
)

pkg/query-service/auth/auth.go Show resolved Hide resolved
pkg/query-service/auth/auth.go Show resolved Hide resolved
ee/query-service/saml/request.go Show resolved Hide resolved
Comment on lines 57 to 58
ValidFrom int64 `json:"ValidFrom"`
ValidUntil int64 `json:"ValidUntil"`
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
ValidFrom int64 `json:"ValidFrom"`
ValidUntil int64 `json:"ValidUntil"`
ValidFrom int64 `json:"validFrom"`
ValidUntil int64 `json:"validUntil"`


if err != nil {
zap.S().Errorf("failed to activate license", zap.Error(err))
return nil, model.BadRequest(err)
Copy link
Member

Choose a reason for hiding this comment

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

model.InternalError would probably more appropriate here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done.

ee/query-service/license/manager.go Show resolved Hide resolved
ee/query-service/app/db/reader.go Show resolved Hide resolved
ee/query-service/app/api/auth.go Show resolved Hide resolved
prashant-shahi and others added 2 commits October 6, 2022 18:29
Signed-off-by: Prashant Shahi <prashant@signoz.io>
chore(ee): 🔧 LD_FLAGS related changes
@sonarqubecloud
Copy link

sonarqubecloud bot commented Oct 6, 2022

SonarCloud Quality Gate failed.    Quality Gate failed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 18 Code Smells

No Coverage information No Coverage information
3.9% 3.9% Duplication

Copy link
Member

@srikanthccv srikanthccv left a comment

Choose a reason for hiding this comment

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

Overall LGTM. Please create an issue for points we decided to continue the discussion.

@ankitnayan ankitnayan merged commit 9c4521b into SigNoz:develop Oct 6, 2022
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.

5 participants