#opendaylight-meeting: MD-SAL call
Meeting started by colindixon at 16:06:18 UTC
(full logs).
Meeting summary
- status update (colindixon, 16:06:47)
- https://meetings.webex.com/collabs/#/meetings/detail?uuid=MCQK23GTHZNO7LDV6UWT6KLYPV-9VIB&rnd=497132.35684
(tbachman,
16:08:24)
- https://git.opendaylight.org/gerrit/#/c/8046/
colindixon points out that tony has pushed a patch with better
documentation thats’s pretty interesting (colindixon,
16:08:33)
- https://git.opendaylight.org/gerrit/#/q/status:merged+project:controller+topic:clustering,n,z
- clustering patches (edwarnicke,
16:08:42)
- https://git.opendaylight.org/gerrit/#/q/project:controller+topic:clustering,n,z
(edwarnicke,
16:09:35)
- the above patches are the start of clustering
support, which is coming in bit-by-bit intentionally to allow it to
be digested easily (colindixon,
16:10:26)
- https://git.opendaylight.org/gerrit/8038
(tbachman,
16:11:29)
- the above patch (8038) provides updated support
for swagger description or RESTCONF APIs and interfaces (colindixon,
16:12:23)
- https://git.opendaylight.org/gerrit/#/c/7917/
potentially interesting patch relating to adding XSQL support (colindixon,
16:13:28)
- Krish asking about how to set up producers and consumers (colindixon, 16:15:08)
- the confusion seems to be whether you should
call ProviderContext.getSALService() vs.
ProviderContext.getRpcService() (colindixon,
16:19:59)
- at least one part of the answer is that
getSALService() is for getting SAL infrastructure services, while
getRpcService() is for getting services which are advertised through
or via the SAL (colindixon,
16:20:44)
- LLDPDiscoveryProvider.java provides an example
where module X notifies module Y which notified module Z
(devinavery,
16:22:25)
- dbainbri asks if we should figure out if we
need to disambiguate between the infrastructure services and the
others? (colindixon,
16:22:31)
- LLDPDiscoveryListener.java listens and then
publishes the notifications. (devinavery,
16:23:16)
- you can do similar things with RPCs that this
example shows with notifications noted above. (devinavery,
16:25:56)
- Krish asks if there’s any documentation that we
could find, the answer is yes (colindixon,
16:26:54)
- https://wiki.opendaylight.org/view/Example_Code
Example code for interacting with MD-SAL (devinavery,
16:27:00)
- https://jenkins.opendaylight.org/controller/job/controller-merge/lastSuccessfulBuild/artifact/target/apidocs/org/opendaylight/controller/sal/binding/api/BindingAwareBroker.ProviderContext.html
(colindixon,
16:29:14)
- the LLDP example is using an
AbstractBindingAwareProvider (LLDPActivator extends the aware
provider) (devinavery,
16:31:31)
- there’s a question about how to be both a
provider and a consumer (colindixon,
16:36:53)
- the answer is that a provider is a strict
superset of consumer, meaning that if you want to be both, you
should only extend the provider (colindixon,
16:37:38)
- https://jenkins.opendaylight.org/controller/job/controller-merge/lastSuccessfulBuild/artifact/target/apidocs/org/opendaylight/controller/sal/binding/api/BindingAwareBroker.ProviderContext.html
(colindixon,
16:45:54)
- ACTION: edwarnicke
will take a first stab fix the comments (today) w.r.t. to the
ProviderContext and ConsumerContext to fix the problem as well as we
can now (colindixon,
16:48:32)
- ACTION: edwarnicke
will update comments on AbstractBindingAware{Provider,Consumer} and
{Producer/Consumer}Context to be clearer that Provider is a superset
of Consumer (edwarnicke,
16:48:57)
- we will work on making the interfaces better on
a deeper level going forward (colindixon,
16:49:02)
- ACTION: devinavery
will follow up on ed's comments (devinavery,
16:49:48)
- Krish points out he’s also confused about the
config subsystem, and is looking for help wherever he can get it:
the wiki, humans, etc. (colindixon,
16:50:47)
- the config subsytem (colindixon, 16:53:21)
- suggestion by krish: in documentation put
pointers to example code that does the thing being documented
(lori,
16:56:13)
- edwarnicke walks through the openflowplugin
config xml (colindixon,
16:56:40)
- it’s called 42-openflowplugin.xml and is in the
openflowplugin-controller-config java project inside the
openflowplugin repo (colindixon,
16:58:09)
- the 42 is basically using /etc/init.d-style
numbering (colindixon,
16:59:34)
- this indicates the order in which configs are
processed (colindixon,
17:00:10)
- question asked why we are embedding numbers for
ordering vs figuring out dependencies (devinavery,
17:01:22)
- answer from ed: There is dependencies and
deterministic start-up (devinavery,
17:01:41)
- main argument from Ed - is deterministic
start-up. Things get unpredictable in terms of start-up time
etc. (devinavery,
17:02:55)
- colindixon disagrees on that start-up
timing. (devinavery,
17:03:25)
- and deterministic start-up. (devinavery,
17:03:43)
- dbainbri asks why we wrote our own version of
Spring-style dependency injection (colindixon,
17:03:57)
- Config System provides runtime reconfiguration
of the system, and one other thing... (missed it) (devinavery,
17:05:19)
- tony responds that there are two things they
needed (i) two-phase resolution of dependencies and (ii) runtime
config modification (colindixon,
17:05:43)
- Argument for runtime configuration - if you
have a running system, and now a new switch comes in a different
port, so you can then change it live (add another listener on the
new port). (devinavery,
17:06:41)
- the two-phase resolution of dependencies I
think is first doing wiring of dependencies and and then resolving
the instances you need and spinning them up (colindixon,
17:06:42)
- dbainbri expresses his doubt that we actually
want to do this live reconfig, but edwarnicke argues vehemently on
the other side (colindixon,
17:08:04)
- dbainbri asks if we change the config file
while it’s running, will the config update. Answer is no, but you
can change it via JMX (I think). (colindixon,
17:08:35)
- ongoing discussions about persisting config
automatically (devinavery,
17:12:08)
Meeting ended at 17:14:22 UTC
(full logs).
Action items
- edwarnicke will take a first stab fix the comments (today) w.r.t. to the ProviderContext and ConsumerContext to fix the problem as well as we can now
- edwarnicke will update comments on AbstractBindingAware{Provider,Consumer} and {Producer/Consumer}Context to be clearer that Provider is a superset of Consumer
- devinavery will follow up on ed's comments
Action items, by person
- devinavery
- devinavery will follow up on ed's comments
- edwarnicke
- edwarnicke will take a first stab fix the comments (today) w.r.t. to the ProviderContext and ConsumerContext to fix the problem as well as we can now
- edwarnicke will update comments on AbstractBindingAware{Provider,Consumer} and {Producer/Consumer}Context to be clearer that Provider is a superset of Consumer
People present (lines said)
- colindixon (49)
- devinavery (14)
- tbachman (9)
- odl_meetbot (5)
- lori (5)
- edwarnicke (4)
- dbainbri (4)
- rovarga (1)
Generated by MeetBot 0.1.4.