===========================================
#opendaylight-meeting: MD-SAL interest call
===========================================


Meeting started by colindixon at 16:07:31 UTC.  The full logs are
available at
http://meetings.opendaylight.org/opendaylight-meeting/2014/md_sal_interest_call/opendaylight-meeting-md_sal_interest_call.2014-07-22-16.07.log.html
.



Meeting summary
---------------

* agenda bashing  (colindixon, 16:07:43)
  * LINK: https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call#Agenda
    the agenda in it’s normal place  (colindixon, 16:08:09)

* status updates  (colindixon, 16:08:29)
  * colindixon is hoping to get DataObject serialization to XML (and
    hopefully JSON) working this week as well as maybe deserialization
    (colindixon, 16:10:59)
  * LINK:
    https://lists.opendaylight.org/pipermail/yangtools-dev/2014-July/000299.html
    some more info here  (colindixon, 16:11:18)
  * the commit() method on transactions is now named submit() and
    consolidates the way you can check how things succeeded or failed
    (colindixon, 16:12:29)

* proposal to change behavior of generated builders  (colindixon,
  16:14:46)
  * LINK: https://bugs.opendaylight.org/show_bug.cgi?id=1097 this is the
    enhancement bug in question  (colindixon, 16:15:16)
  * the core issue is that right now we allow for both a null list and
    an empty list as different things  (colindixon, 16:17:24)
  * the proposal is to stop allowing for lists to be null  (colindixon,
    16:18:35)
  * this means that some code may currently be using that to
    differentiate between a not-present list and an empty list
    (colindixon, 16:20:12)
  * dbainbri asks if there’s any code that this will affect
    (colindixon, 16:20:36)
  * tony responds that the openflowplugin stopped producing the topology
    because it assumed that non-null lists were not empty  (colindixon,
    16:21:25)
  * LINK:
    https://lists.opendaylight.org/pipermail/controller-dev/2014-July/005811.html
    this is the mailing list discussion (which is largely in favor of
    making null and empty list the same thing)  (colindixon, 16:23:47)
  * devinavery asks “Since we have no real objections, how are we going
    to go about merging this patch?”  (colindixon, 16:29:34)
  * colindixon says there are really two issues: (1) do we have to
    change the version of the generated code when the compiler changes,
    and (2) can we allow people to stay working on older versions of
    artifacts within reason?  (colindixon, 16:31:15)
  * tony says that w.r.t. (1) there’s a “v1” in the package name of
    generated code which corresponds to the binding interface version
    and we should probably increment that as part of this, although
    there’s some concern about how to do minor vs. major versioning
    there  (colindixon, 16:32:02)
  * edwarnicke says that w.r.t. (2) we’re almost there because we cut
    weekly releases of all projects every sunday  (colindixon, 16:32:47)
  * colindixon says that’s all well and good but we don’t have a
    mechanical way to allow people to roll back to the last weekly
    release across the board, the weekly releases border on useless
    (colindixon, 16:34:36)
  * devinavery tries to push us back to the real discussion: there are
    two proposals: (i) push the change today and give people the rest of
    the week to fix it and (ii) give people the warning and then push
    the change on monday  (colindixon, 16:41:21)
  * a third proposal from dbainbri is to push it now, but with a version
    tick  (colindixon, 16:41:41)
  * a long discussion goes on (see IRC and/or recording) where it seems
    as though a version tick in the pom.xml file won’t solve the problem
    because you can end up with different bundle using different
    versions of the model which are now indistinguishable  (colindixon,
    16:49:21)
  * as a consequence, the plan of record is to merge this change on
    Monday 7/28 after sending an e-mail to warn people  (colindixon,
    16:50:33)

* changes in RESTCONF to support AAA  (colindixon, 16:50:57)
  * the currently the RESTCONF is hard-wired to the data broker (which
    doesn’t support AAA)  (colindixon, 16:52:10)
  * to provide AAA, we need to have a configurable wiring of RESTCONF
    onto a backing implementation that can support AAA  (colindixon,
    16:52:40)
  * the proposal is to make RESTCONF something that the config subsystem
    can manage so this can be done  (colindixon, 16:53:59)
  * edwarnicke asks if there’s anything else that needs to be changed in
    RESTCONF to make sure that it passes appropriate authentication
    context as well  (colindixon, 16:54:45)
  * answer is no  (colindixon, 16:54:48)



Meeting ended at 16:59:40 UTC.



People present (lines said)
---------------------------

* colindixon (35)
* Madhu (18)
* edwarnicke (15)
* rovarga_ (12)
* dbainbri (7)
* odl_meetbot (3)
* devinavery (2)
* tbachman (1)



Generated by `MeetBot`_ 0.1.4