NETCONF actions/RPCs

[alexandernorth]

In order to complete day-1 configuration for some NFs, we need to be able to perform NETCONF actions, which have their names and parameters defined in the YANG schema.

Upon initial investigation along with @steiler, we compiled a list of items a solution should consider and reason about:

• Are they only related to config?
  • hook them to config
  • have a separate Actions CRD
• For config related actions
  • we might need pre- and post-commit actions
  • what about intermediate actions? Do such things exist?
    • could these be chopped into pieces such that we have pre-/post-actions again
• what about re-applying the intent because the target is re-added to the dataserver
  • are there actions that must only be called once on initial deployment of the intent?
  • when to call stuff relative to the transaction?
    • e.g. is it called after the config is deployed network wide or per device after the config is applied?
  • how to revert in case of transaction revert

These can and will likely be expanded on as more requirements and use cases are discovered.

[henderiw]

High level thoughts discussed during meet-up

• define a ActionCR
• spec:
  • type: pre/post
  • input: ...

to be supported

• status reporting -> in config CR or action CR
• referencing: 1:1 or 1:N
• transactions/rollback -> if post fails rollback the transaction.
• action: on failure

separate action CR or not? seems better to have a dedicated ActionCR

separate RPC services between config server and data server -> use transaction RPC or dedicated action RPC with the transactionReference being the same.

• TransactionStart
• ....
• TransactionEnd/TransactionCancel

[henderiw]

Do we need to validate this in the device schema? -> according to Netconf device schema.