-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
feat: enterprise edition #1575
Conversation
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>
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 |
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.
- url: tcp://stagingapp.signoz.io:9000/?database=signoz_metrics | |
- url: tcp://localhost:9000/?database=signoz_metrics |
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 will remove this file from PR.
type ErrEmailRequired struct{} | ||
|
||
func (errEmailRequired ErrEmailRequired) Error() string { | ||
return "email is required" | ||
} |
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 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
?
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 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.
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 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")
)
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 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:
....
}
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 | ||
} |
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.
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.
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 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.
EE build changes - Docker files and Makefile
type ErrEmailRequired struct{} | ||
|
||
func (errEmailRequired ErrEmailRequired) Error() string { | ||
return "email is required" | ||
} |
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 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")
)
ee/query-service/model/license.go
Outdated
ValidFrom int64 `json:"ValidFrom"` | ||
ValidUntil int64 `json:"ValidUntil"` |
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.
ValidFrom int64 `json:"ValidFrom"` | |
ValidUntil int64 `json:"ValidUntil"` | |
ValidFrom int64 `json:"validFrom"` | |
ValidUntil int64 `json:"validUntil"` |
ee/query-service/license/manager.go
Outdated
|
||
if err != nil { | ||
zap.S().Errorf("failed to activate license", zap.Error(err)) | ||
return nil, model.BadRequest(err) |
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.
model.InternalError would probably more appropriate here.
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.
done.
fix: move usage reporting to top level ee folder
Signed-off-by: Prashant Shahi <prashant@signoz.io>
chore(ee): 🔧 LD_FLAGS related changes
SonarCloud Quality Gate failed. 0 Bugs No Coverage information |
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.
Overall LGTM. Please create an issue for points we decided to continue the discussion.
This PR introduces: