#opendaylight-meeting: MD-SAL interest call
Meeting started by colindixon at 16:03:18 UTC
(full logs).
Meeting summary
- agenda bashing (colindixon, 16:03:23)
- https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call#Upcoming_Agenda_Topics
(colindixon,
16:03:33)
- the only topic we have scheduled for today is
to talk about the migration to jersey 2 (colindixon,
16:04:29)
- https://git.opendaylight.org/gerrit/#/c/27052
TomP would like to discuss the design proposal here (colindixon,
16:05:33)
- things coming down the pipe (colindixon, 16:06:33)
- https://git.opendaylight.org/gerrit/#/q/topic:bug2399
the last patch of a series to fix BUG-2399 (colindixon,
16:07:52)
- https://bugs.opendaylight.org/show_bug.cgi?id=2399
the bug (colindixon,
16:08:03)
- the last patch is still being tested and is
close to being merged, it has to do with automatic creation and
removal of containers when there are no more leaves (colindixon,
16:08:54)
- there is also a new parser coming in, which has
been in development since early Lithium (colindixon,
16:09:47)
- https://github.com/opendaylight/yangtools/tree/master/yang/yang-parser-impl/src/main/java/org/opendaylight/yangtools/yang/parser/impl
(colindixon,
16:10:53)
- it replaces the old parser with a new one that
is more focused on providing better extensibility, e.g., even the
YANG natifve stuff is treated as an extions (colindixon,
16:12:04)
- ACTION: ttkacik to
send out links to the exact packages for the new vs. the old
parser (colindixon,
16:12:29)
- https://github.com/opendaylight/yangtools/tree/master/yang/yang-parser-impl/src/main/java/org/opendaylight/yangtools/yang/parser/impl
I think both implementations are here (colindixon,
16:12:41)
- jersey 2 (colindixon, 16:15:28)
- https://git.opendaylight.org/gerrit/#/q/status:open+project:controller+branch:master+topic:jersey2-migration
jersey 2 patches (colindixon,
16:15:46)
- https://lists.opendaylight.org/pipermail/controller-dev/2015-September/010376.html
mailing list thread (colindixon,
16:15:54)
- https://bugs.opendaylight.org/show_bug.cgi?id=2515
the bug in question (colindixon,
16:16:11)
- ryan goulding says that he needs support for
jersey 2 for AAA, he’s just curious what the state is (colindixon,
16:16:51)
- ttkacik says that the patches need to be picked
up and updated (colindixon,
16:17:33)
- Ryan asks if he can help out (colindixon,
16:17:41)
- ttkacik says that he’d love to see help in
getting these patches working in the NETCONF project (colindixon,
16:18:13)
- colindixon asks if there are any problems we
should expect (colindixon,
16:18:56)
- ttkacik and ryan say that neutron might be a
pain, but it should be mostly easy (colindixon,
16:19:14)
- NETCONF clustering (colindixon, 16:20:52)
- https://git.opendaylight.org/gerrit/#/c/27052
this is the NETCONF clustering design docs (colindixon,
16:21:22)
- essentially, there is a move to put the NETCONF
configuration data and things in the config data store instead of
the config subsystem so that it will be replicated (colindixon,
16:25:37)
- this will use the entity ownership service to
establish who is supposed to talk to a given NETCONF device
(colindixon,
16:26:40)
- the idea is that there is a global topology
manager which manages the high-level stuff, then the node manager
runs one per NETCONF device and deal with per-device issues
(colindixon,
16:27:55)
- NETCONF call home (device to controller
connections) is discussed, but not planned in Beryllium (colindixon,
16:28:19)
- there will be no clustering support for
config-subsystem managed NETCONF devices (colindixon,
16:33:29)
- there will be no support for clustering the
controller-config NETCONF device (e.g., NETCONF NB) because it would
be a diffferent devices on every node as it’s a loopback interface
in some sense (colindixon,
16:34:07)
- the hope is to abstract out the netconf details
and maybe make it usable for others (colindixon,
16:34:34)
- tom pantelis asks if there’s a way to migrate
existing config-subsystem configured NETCONF connections to
this (colindixon,
16:40:23)
- ttkacik says yes, we could write an adaptor but
he recommends that it be opt-in, not opt-out (colindixon,
16:41:00)
- in particular that’s to avoid the interactions
between clustering and the NETCONF NB which the controller exports
and mounts as a loopback (colindixon,
16:41:53)
- TomP asks about how we will migrate an
installation of OpenDaylight with old-style config-subsystem-based
NETCONF connected devices (colindixon,
16:44:37)
- rovarga basically says we can’t think about
this until we have a broader upgrade process worked out (colindixon,
16:45:03)
- colindixon asks if moving the config file XML
to the data store would literally be copying XML snippets and
pasting them (colindixon,
16:46:30)
- rovarga says no, it’s likely going to involve
some transform (colindixon,
16:46:44)
- ttkacik says that it should be pretty easy to
write a script that copies the 4-5 fields crom one place to
another (colindixon,
16:47:15)
- MD-SAL project migration (colindixon, 16:51:37)
- ttkacik says that the only thing that needs to
happen is to do some ping-pong work between the MD-SAL and the
controller project to keep the older APIs in place (colindixon,
16:52:11)
- ttkacik says that most of the code won’t be
removed from the controller (except DOMBrokerImpl and
BindingBroker) (colindixon,
16:52:40)
- it’s more complicated than the NETCONF which
had no public Java APIs (colindixon,
16:53:06)
- TomP asks are we moving sal-common-api? when
are we going to? how can TomP help? TomP needs it for the entity
ownership service (colindixon,
16:53:45)
- ACTION: TomP and
ttkacik to work together on when to merge that (colindixon,
16:54:00)
- anipbu says that there are four projects still
that haven’t merged the MD-SAL migration patches (colindixon,
16:54:15)
Meeting ended at 16:55:31 UTC
(full logs).
Action items
- ttkacik to send out links to the exact packages for the new vs. the old parser
- TomP and ttkacik to work together on when to merge that
People present (lines said)
- colindixon (50)
- odl_meetbot (3)
Generated by MeetBot 0.1.4.