-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Add more northbound operation types #14542
Conversation
3cbca7c
to
b87a4a6
Compare
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
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.
Would it be clearer to add a new 'exclusive' op instead of changing the existing CREATE op - like NB_OP_CREATE_EXCLUSIVE? That'd reduce the impact on existing users, while making the new semantic clear.
Sounds reasonable. I'll update the PR a bit later. |
a8c4bb3
to
4081040
Compare
e51058d
to
cabf424
Compare
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
Currently, nb_operation enum means two different things - edit operation type (frontend part), and callback type (backend part). These types overlap, but they are not identical. We need to add more operation types to support NETCONF/RESTCONF integration, so it's better to have separate enums to identify different entities. Signed-off-by: Igor Ryzhov <[email protected]>
Currently, there's no difference between CREATE and MODIFY operations. To be compatible with NETCONF/RESTCONF, add new CREATE_EXCL operation that throws an error if the configuration data already exists. Signed-off-by: Igor Ryzhov <[email protected]>
Currently, there's a single operation type which doesn't return error if the object doesn't exists. To be compatible with NETCONF/RESTCONF, we should support differentiate between DELETE (fails when object doesn't exist) and REMOVE (doesn't fail if the object doesn't exist). Signed-off-by: Igor Ryzhov <[email protected]>
Signed-off-by: Igor Ryzhov <[email protected]>
Replace operation removes the current data node configuration and sets the provided value. As current northbound code works only with one xpath at a time, the operation only makes sense to clear the config of a container without deleting it itself. However, the next step is to allow passing JSON-encoded complex values to northbound operations which will make replace operation much more useful. Signed-off-by: Igor Ryzhov <[email protected]>
Signed-off-by: Igor Ryzhov <[email protected]>
cabf424
to
7e48299
Compare
@@ -186,12 +186,12 @@ static int frr_sr_process_change(struct nb_config *candidate, | |||
/* Map operation values. */ | |||
switch (sr_op) { | |||
case SR_OP_CREATED: | |||
nb_op = NB_OP_CREATE; | |||
break; |
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.
This is no longer behing checked for validatity/allowed, is that ok?
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.
NB_OP_CREATE
is always allowed, even for list keys, so there's no need for additional checks.
There's still a check in SR_OP_MODIFIED
case to ignore changes to list keys.
Currently, we basically support two types of configuration edit operations:
merge
: modify existing data or create if it doesn't exist (NB_OP_CREATE/NB_OP_MODIFY, both do the same thing)remove
: delete data if it exists, ignore otherwise (NB_OP_DESTROY)To be able to integrate with NETCONF/RESTCONF servers, this PR adds three more operation types:
create
: create new data, fail if it already exists (new NB_OP_CREATE_EXCL operation)delete
: delete data, fail if it doesn't exist (new NB_OP_DELETE operation)replace
: replace config with a new one, create if it doesn't exist (new NB_OP_REPLACE operation)Important note:
DELETE_DATA
operation in mgmtd frontend API now fails if the data already exists. To have the old behavior, one should use newREMOVE_DATA
operation. However, it's only an API change. From the ABI perspective nothing has changed, so existing applications that work with mgmtd frontend API won't break. The behavior will change only once the developer rebuild their application using the updatedlib/mgmt.proto
definitions.It's easier to review the changes commit by commit.