forked from sonic-net/sonic-mgmt-framework
-
Notifications
You must be signed in to change notification settings - Fork 15
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
pattern PTYPE need to be presented in more cleaner way #68
Comments
@ranjinidn -- any update? |
Not had a chance to look a it. Will have to look at it after transformer tasks. |
joyas-joseph
pushed a commit
that referenced
this issue
Nov 12, 2020
1) If a REST request fails due to cvl error, all non-zero values from CVLErrorInfo object will be encoded in the "error-info" field of response data (RFC8040 section 7.1). The "error-info" value will be a josn object with one field "cvl-error", whose value will be an object containing data from CVLErrorInfo. "error-info": { "cvl-error": { "error-code": <CVLErrorInfo.Code>, "description": <CVLErrorInfo.CVLErrDetails>, "message": <CVLErrorInfo.Msg>, "table-name": <CVLErrorInfo.TableName>, "table-keys": <CVLErrorInfo.Keys>, "field-name": <CVLErrorInfo.Field>, "field-value": <CVLErrorInfo.Value>, } } ErrAppTag and ConstraintErrMsg are not included here since they will be encoded in "error-app-tag" and "error-message" fields of the error object. The "error-info" may include other error details in future. Clients should check for the presence of "cvl-error" field to identify CVL error. 2) REST server recovers panicking request handlers to return an error status 500 (internal server error) to the clients. Writes an error log with "runtime error" prefix, which can be used to redirect such messages to the device console (requires rsyslog config enhancements). Previously, the panics would have abruptly closed client connection without proper logs or messages. 3) Changed REST server to log all client data validation and translib errors as warnings. They need not be errors in client app's context. Errors returned by system APIs continue to get logged as error message. This helps better monitoring and filtering of log messages.
sameerdell
pushed a commit
that referenced
this issue
Mar 15, 2022
…o-dell_sonic_share sync from broadcom_sonic_share to dell_sonic_share - 0310
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
if we give PTYPE as a pattern(like MTU – 1312-9216).
Say, if I specify MTU as PTYPE of pattern 1312..9216,
When we go to each level of command it’s presenting a bit different compared to how it is in OS10 supported by CLI Infra. Could you give your inputs on this?
For example,
In Sonic,
sonic(conf-if-Ethernet12)# mtu
MTU of the interface (1312..9216)
In OS10,
OS10(conf-if-eth1/1/2)# mtu
<1312-9216> Configure interface MTU size (IP MTU=interface MTU - L2 header
The text was updated successfully, but these errors were encountered: