[dev] notes from frr api discussion, 5/4/18

[Mark Stapp]

Donald organized a conference call to focus on management and api issues.
He suggested that I send around my notes, to give folks some overview of
the discussion. I don't have a full attendee list, I'm sorry to say. And of
course, if I've misrepresented something that someone said, please feel
free to correct "the record"...

* preso from 6Wind about their use of vty
** using xml transport between their own mgmt system and converting to vty
** command ordering an issue in cli/vty, as is feedback/validation
** planning to go forward with a yang-based schema, want api access,
   believe cli and api need to be converged as a single path

** Q from Donald: how do you handle shared objects, like route-map,
   acl, and prefix-list. "it's important that whatever solution we have
   understands that we have some shared/universal data"

** Renato W. gave a verbal overview of his 'northbound' proposal that has
been mentioned on the regular dev call and in the yang slack channel; he
will present slides and details soon

we tried to list a few higher-level points :

* attributes or objects? are we configuring individual attributes, or
entire objects (or lists of objects)?
* validation/handling logic inside daemons: what do they need to be able to
do internally to ensure correctness, and what can be done by model-level
validation (a benefit of models)?
* sync  vs. async (for transport, and for interaction with the daemon code)
* shared/global objects (along the lines of Donald's point from earlier)
* locking (per-attr? per-object? per-transaction - whatever that is?) what
are the sorts of needs and expectations as we see more multi-threading in
frr?
* multi-admin (transactions concept): is this something that is a goal for
frr, or is it the responsibility of external management systems?
* impact on code (cli, running/protocol code, opportunity to auto-generate
some config handler code?)
* performance/mem - input of large config, paging of large data sets, e.g.
* error-handling, feedback
* multi-daemon, multi-process coordination (ease of daemon management,
  "it's really hard to set up mpls right now" [DS]
  ** behavior on restart among daemons, e.g.

we discussed a follow-on meeting to continue the discussion, time tbd...

Cheers,
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20180504/31d35237/attachment.html>