ctrl:action yang spec and hook

[JohannesGarm]

Yang spec for and detection of an action marker which allows for evoking pyapi module functions via the api.

Example yang:

 grouping filter-update {
        ctrl:action update {
            description "Update filter";
            ctrl:actionhook filter-update { }
            input {
                leaf device-group {
                    type leafref { path "/ctrl:devices/ctrl:device-group/ctrl:name"; }
                }
                leaf force { type boolean; default false; }
            }
            output {
                leaf result { type string; }
            }
        }
    }

Here, the ctrl:action marker is used to indicate we are specifying a function to be evokable via the pyapi. The ctrl:actionhook indicates which function in the pyapi module is to be called and the input and output leaves indicate the footprint of the function.

The important bit here is that you can specify a function to be evokable via the pyapi, not the exact syntax in the yang or implementation details.

[olofhagsand]

This needs more investigation. First, clixon supports actions as in https://www.rfc-editor.org/rfc/rfc7950.html#section-7.15, which would mean that the syntax above could read as:

grouping filter-update {
       action update {

with input/output as in the example. However, actionhook is not standard. And also it is unclear to me what this means:

evokable via the pyapi.

Actions in clixon are implemented by registering a function for the action. In this case I suppose that would mean some glue / callbacks is necessary to relay this callback to the pyapi, so that the corresponding python code (filter-update) is executed, if this is what is expected? Who calls this action BTW? Is it an external call from outside using NETCONF or RESTCONF for example, or is it the CLI?

[krihal]

is this still something we need?

[JohannesGarm]

This was intended for recalculating the filter services - in this case the values of the service instance have not changed but the values fetched via bgpq4 have. So a mechanism for recalculating a service in order for sideeffects (bgpq4) to be triggered and new config generated. This could be "hacked" with the current functionality by adding an "updated_at" field to the service code but in the long term a cleaner solution for triggering a re-deploy would be good.