See attached files for raw notes.
--Colin
Moving to RESTCONF draft 15, 16?, 17?, RFC?
* when should we even advertise that it exists?
* when it's an formal RFC?
* and YANG 1.1 support?
* Colin and Ryan say we should probably wait?
* Robert suggests advertise it with the caveat that it's a moving
target?
* we ship draft 15 in Boron
* Robert suggests break the API and move to draft 16 in SR1
* still don't use it as a primary API
* should we deprecate/remove draft 02? when?
* now?
* never?
* Colin and Ryan mostly say, never.
* Robert says deprecate as soon as the final RFC is implemented
* Removal, we need to talk to the advisory group
* he really hopes that the answer isn't 5 years
* maybe deprecate => disable by default => remove
RESTCONF Query/Filter:
We need a way for applications to query the data they need and not get tons of
information back over RESTCONF. The issue with table features for Open vSwitch
returning megabytes of data per switch is just one example.
You can make a query further down to the tree?
* Yes, but it doesn't necessarily help because you can't get a leaf without
getting a subtree that is at the same level?
* There is a depth parameter
* do we implement it?
* I think not in draft02, but is in draft15
* if so, is it sufficient?
* you can (in theory) do a breadth-first search (by using depth=)
* this involves a large number
* We need to be able to get a subset of of data from RESTCONF
* Do we care about doing actual querying or just removing parts of the
data?
* If it's the latter, then it's a lot easier
* Query/Filter language
* Xpath
* XSL (wraps Xpath to be able to queries across subtrees)
* XQuilla (and implementation of XSL, w3c open source project)
* Where to do the querying and filtering
* at the RESTCONF level, outside the controller
* get the XML
* run query
* return result
* client is protected from gobs and gobs of data
* only has to pass over localhost if you do it right
* doesn't protect resource consumption at the controller
* you could do it on DOM inside?
* how would this perform?
* could you implement it a as a new kind of listener?
* How do we pass a query/filter over RESTCONF:
* do we need an extension to RESTCONF?
* a different (non-RESTCONF) API
Actions:
1.) see how far we can get with just depth= limits
2.) discussions of the simplest useful to get some real querying
BGP Unification:
We have (at least) four different places we use BGP:
* netvirt (quagga?)
* bgpcep
* atrium (quagga?)
* sdninterfaceapp
* just needs to work with bgpcep to get off their fork
Trade-offs:
* quagga is more mature, more featured, ...
* bgpcep is java and YANG-ified
Goal:
* could we define an interface for BGP service which could be backed by either
bgpcep or Quagga (or whatever in the future)?
* right now vpnservice/netvirt uses a thrift interface to talk to Quagga
* if we moved to using a YANG like interface, we would need it to be
fast enough
* right now, we need 2000 routes/second from BGP routes to flows in the
network
* claim is that YANG MD-SAL operations per second is ~20,000 ops/second
(I think)
* that might be enough
* the clustered data store seems to be the real culprit for speed
* things are seeming to move toward OpenConfig, maybe that would be a good
standard description of the BGP service
Action items:
* sdninterface app to move off fork
* provide a way to slide Quagga in under OpenConfig?
* Giles says he worries about what the effort is to translate all the
thrift configuration of Quagga
* how much of Quagga config are we using and how much work is it to
move to OpenConfig as the top-level model
* Robert suggests that you might instead just peer with the Quagga instance
using bgpcep
* the problem right now is that we don't get a FIB from bgpcep
* netvirt/vpnservice is using the RIB from Quagga
* could we build an abstract FIB interface
* you will need other sources to be able to populate the FIB other than
BGP
* is the FIB service really just the Forwarding Rules Manager?
* could we migrate it to being the right thing
* grouping for ECMP, what else?
* make sure we keep the KPIs up as we do all of this
What do we want to do with upgrades:
* per feature
* per node
Assumptions:
* we will not do ISSU to start?
* not do in place upgrades inside a JVM?
* can we get away without doing in-place upgrades inside a cluster?
Let's do the easiest thing first:
* do we need it to be hitless?
* I'd argue for now, we don't need it to be hitless, we just need it to be
automated
* cofiguraion
OpenDaylight Upgrades:
1.) code upgrades (changing the actual artifacts)
2.) configuration upgrades (all the xml files from Config Subsytem)
* the hope is that this really becomes 3
* except for a few things that have to load before the data store
3.) data upgrades (stuff stored in the MD-SAL)
* schema migration: well studied in RDBMSes (flyway, liquidbase)
* we really want one upgrade "script" which then calls (per-model?
per-project?) sub-scripts which can do individual bits of data munging
* we probably (at least eventually) need a maintenance mode which loads
the data store and YANG models, but not any bundles that will take action
Other things:
* Karaf?
* Akka config files?
* already done, handled in upgrades
* Needs to be tied into HA.
* at least in the long run, want to be able to do zero-downtime upgrades
*
Maybe look at Cisco open source project to generate code to help translate one
version of a model to another as configured via a GUI. (Get it from Jan.)
Lost structure:
* JSON loses information
Java frameworks from mapping one Java type to another:
* Dozer
* Mapstruct
OpenDaylight startup/shutdown:
* how do we know when the controller is up?
* what do we mean by up?
* all expected bundles/features are up
* and "ready" (we can do this when things call start() or
init())
* we can wait for somebody else to come up in the init() metho
* what are we expecting to come up?
* can we enumerate all the bundles/features we're expecting to
come up
* we could do this by hand and the store it as metadata
* can we do it automatically?
* get a list of all the "installed" features the user
has asked for
* the use that to figure out what you're expecting to
come up
* many current apps have a YANG model where they write a sentinel value
to say they're up
* is this a good idea?
* can we formalize it?
* all ODL features/modules (what's the right granularity?)
* can we get graceful shutdown?
* basically, we just need to ask people to do it?
* how do you test it?
* gone to installed or resolved
* are your services unregistered
* best practices about what to put in it?
* any special stuff we need to do for dependencies? unload YANG models?
* TWS + some documentation?
* key goal:
* get a consistent state so that you can do things like upgrades
* also so that when you come back up, things are OK
* ask about this in Carbon
_______________________________________________
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev
