#opendaylight-meeting: tws

Meeting started by colindixon at 17:00:56 UTC (full logs).

Meeting summary

  1. agenda bashing (colindixon, 17:01:01)
    1. https://wiki.opendaylight.org/view/Tech_Work_Stream:Main#Upcoming_Meeting_Agendas today’s agenda (colindixon, 17:01:33)

  2. IT good practices followed in OVSDB project (Madhu, 17:05:45)
    1. https://wiki.opendaylight.org/view/OVSDB:Continuous_Integration (hideyuki, 17:05:51)
    2. https://wiki.opendaylight.org/view/OVSDB:Continuous_Integration overview of the CI (Madhu, 17:05:57)
    3. https://jenkins.opendaylight.org/ovsdb/job/ovsdb-ovs-integration/ is a multi-configuration matrix jenkins job (Madhu, 17:07:28)
    4. right now ovsdb runs ovsdb-verify and ovsdb-ovs-integration whenever a patch is submitted (colindixon, 17:07:40)
    5. the above ovsdb-ovs-integration job is used as verify job to run every commit across various versions of OVS (Madhu, 17:08:00)
    6. https://github.com/dave-tucker/docker-ovs the Optimized Docker container with OVS user-space mode (Madhu, 17:08:41)
    7. with this user-space OVS, we are able to run many many OVS versions in a single VM. (Madhu, 17:09:18)
    8. yes, that’s ~30MB in size :) (tbachman, 17:09:41)
    9. http://buildroot.uclibc.org/ is used to build a super-optimized for our use-case. (Madhu, 17:09:54)
    10. the super-optimized user-space OVS is between 26MB - 35MB (Madhu, 17:10:20)
    11. multi-configuration matrix jenkins job will run every version of OVS version configured for (Madhu, 17:11:33)
    12. https://jenkins.opendaylight.org/ovsdb/job/ovsdb-ovs-full-integration-daily/ runs daily and we test across 16 versions of OVS (Madhu, 17:12:01)
    13. the key way to adopt this is to start figuring out how to build your own optimized docker images for things you need (colindixon, 17:17:36)
    14. it took dave_tucker and Madhu two weeks or so to get their OVS docker image up, working and minified (colindixon, 17:18:04)
    15. dave_tucker says that docker works best with things that have 2-3 processes (not many more) (colindixon, 17:20:03)
    16. for things with more processes, using a vagrat VM is more useful (colindixon, 17:20:20)

  3. sonar job (colindixon, 17:20:24)
    1. this runs on code being mreged (alongside the normal merge job) (colindixon, 17:20:51)
    2. https://jenkins.opendaylight.org/ovsdb/job/ovsdb-code-coverage/ ovsdb code-coverage job (Madhu, 17:21:00)
    3. Sonar overall-reporting is misleading because it doesn't include IT coverage if the bundle dent do UT (Madhu, 17:23:02)
    4. https://git.opendaylight.org/gerrit/gitweb?p=ovsdb.git;a=blob;f=commons/parent/pom.xml;h=2e7805d5f90afb7f2af54f055ab6f9204fbff787;hb=refs/heads/master OVSDB pom.xml which takes care of all the required UT, IT and jacoco configuration (Madhu, 17:23:34)
    5. https://git.opendaylight.org/gerrit/#/c/9482/2 Fix for including PAX-Exam in Sonar Coverage (Madhu, 17:24:15)
    6. the issue with PAX-Exam coverage issue was due to the missing common base coverage directory (Madhu, 17:25:01)
    7. part of getting accurate sonar code coverage is specifying some extra parameters, e.g., specifying the root directory to be able to catch the cross-bundle code coverage from integration tests (colindixon, 17:25:33)
    8. jacoco maven plugin that is used for code-coverage reports (Madhu, 17:26:30)
    9. Sonar reports both the IT test-cases and UT Test-cases under the UT coverage (Madhu, 17:27:19)
    10. some configuation of jacoco for specifiy the report file and the append=true part (colindixon, 17:27:31)
    11. to get IT results in the same place as UT, you need a configuration from the failsafe plugin to put the report in the same place as surefire-reports (colindixon, 17:28:31)
    12. We are running Sonar 4.3.2 (Madhu, 17:29:17)
    13. https://github.com/dave-tucker/sonar-vagrantbox Sonar lite version (Madhu, 17:31:05)
    14. somebody asks whether you need sonar? dave_tucker says that you get a report, but it’s harder to interpret them without help (colindixon, 17:32:26)
    15. though surefire reports are useful, Sonar does a good job in aggregating the reports and provide a much better coverage report and details (Madhu, 17:33:38)

  4. Test Documentation (Madhu, 17:34:38)
    1. Integration project team was looking for test case documentation from each project. (Madhu, 17:34:57)
    2. Testopia is certainly an option. But it doesn't follow the Code closely. So we agreed on using Javadoc (Madhu, 17:35:31)
    3. right now, the ovsdb team documents the tests in the code whereyou can see them from the sonar screen (colindixon, 17:37:18)
    4. we can do inline Javadoc for the tests so that Integration team and others can understand what each test case is covering (Madhu, 17:38:34)
    5. in the future, the hope is to be able to add a javadoc tab in sonar that provides just documentation (colindixon, 17:38:41)
    6. https://wiki.opendaylight.org/view/Tech_Work_Stream:Main (colindixon, 17:51:15)
    7. ACTION: colindixon to document how to easily enable checkstyle for your project/bundle (colindixon, 17:52:37)
    8. please let us know if you are interested in hearing about any specific topic (Madhu, 17:55:42)


Meeting ended at 17:55:44 UTC (full logs).

Action items

  1. colindixon to document how to easily enable checkstyle for your project/bundle


Action items, by person

  1. colindixon
    1. colindixon to document how to easily enable checkstyle for your project/bundle


People present (lines said)

  1. Madhu (32)
  2. colindixon (23)
  3. odl_meetbot (6)
  4. tbachman (6)
  5. hideyuki (1)


Generated by MeetBot 0.1.4.