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

pattern PTYPE need to be presented in more cleaner way #68

Open
justinejose91 opened this issue Aug 7, 2019 · 2 comments
Open

pattern PTYPE need to be presented in more cleaner way #68

justinejose91 opened this issue Aug 7, 2019 · 2 comments
Assignees

Comments

@justinejose91
Copy link

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

@jeff-yin
Copy link
Collaborator

@ranjinidn -- any update?

@ranjinidn
Copy link
Collaborator

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants