为 netconf 编辑配置请求创建原子进程

Question

I am creating a custom system that, when a user submits a netconf edit-config , it will initiate a set of actions in my system that will atomically alter the configuration of our system and then submit a notification to the user of its success or failure.

Think of it as a big SQL transaction that, at the end, either commits or rolls back.

So, steps

1. User submits an edit-config
2. System accepts config and works to implement this config
3. If the config is successful, sends by a thumbs up response (not sure the formal way of doing this)
4. If the config is a failure, sends by a thumbs down response (and I will have to make sure the config is rolled back internally)
5. All this is done atomically. So, if a user submits two configs in a row, they won't conflict with each other.

Our working idea (probably not the best one) to implement this was to go about this by accepting the edit-config and then, within sysrepo, we would edit parts of our leafs with the success or failure flags and they would happen within the same session as the initial change. We were hoping this would keep everything atomic; by doing edits outside of the session, multiple configuration changes could conflict with each other.

We weren't sure to go about this with pure netconf or to leverage sysrepo directly. We noticed all theseplugins/bindings made for sysrepo and figured those could be used directly to talk to our datastore.

But that said, our working idea is most likely not best-practice approach. What would be the best way to achieve this?

Our system is:

• netopeer 1.1.27
• sysrepo 1.4.58
• libyang 1.0.167
• libnetconf2 1.1.24

And our yang file is

module rxmbn {
  namespace "urn:com:zug:rxmbn";
  prefix rxmbn;

  container rxmbn-config {
    config true;
    leaf raw {
      type string;
    }
    leaf raw_hashCode {
      type int32;
    }
    leaf odl_last_processed_hashCode {
      type int32;
    }
    leaf processed {
      type boolean;
      default "false";
    }
  }
}

Currently we can:

• Execute an edit-config to netopeer server
• We can see the new config register in the sysrepo datastore
• We can capture the moment sysrepo registers the data via sysrepo's API

But we are having problems

• Atomically editing the datastore during the update session (due to locks, which is normal. In fact, if there is no way to edit during an update session, that is fine and not necessary. The main goal is the next bullet)
• Atomically reacting to the new edit-config and responding to the end user

We are all a bit new to netconf and yang, so I am sure there is some way to leverage the notification api or event api either through the netopeer session or sysrepo, we just don't know enough yet.

If there are any examples or implementation advice to create an atomic transaction for this, that'd be really useful.

Answer 1

I know nothing of sysrepo so this is from a NETCONF perspective.

NETCONF severs process requests serially within a single session in a request-response fashion, meaning that everything you do within a single NETCONF session should already be "atomic" - you cannot send two requests and have them applied in reverse order or in parallel no matter what you do. A well behaved client would also wait for each response from the server before sending a new request, especially if all updates must execute successfully and in specific order. The protocol also defines no way to cancel a request already sent to a server.

If you need to prevent other sessions from modifying a datatstore while another session is performing a multi- edit-config, you use <lock> and <unlock> NETCONF operations to lock the entire datastore. There is also RFC5717 and partial lock, which would only lock a specific branch of the datastore.

Using notifications to report success of an <edit-config> would be highly unusual - that's what <rpc-reply> and <rpc-error> are there for within the same session. You would use notifications to inform other sessions about what's happening. In fact, there are standard base notifications for config changes.

I suggest reading the entire RFC6241 before proceeding further. There are things like candidate datastores, confirmed-commits, etc. you should know about.