========================
#opnfv-joid: JOID weekly
========================


Meeting started by arturt at 17:05:22 UTC.  The full logs are available
at
http://ircbot.wl.linuxfoundation.org/meetings/opnfv-joid/2016/opnfv-joid.2016-11-23-17.05.log.html
.



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

* Artur Tyloch  (arturt, 17:05:29)
* Agenda bashing  (arturt, 17:05:53)
  * LINK: https://etherpad.opnfv.org/p/joid  (arturt, 17:05:58)
  * Narinder Gupta  (narindergupta, 17:05:59)
  * Bryan Sullivan  (bryan_att, 17:08:00)

* Colorado release  (arturt, 17:10:50)
  * OCL status - close to solution  (arturt, 17:11:21)
  * stability issues Narinder is working on  (arturt, 17:12:12)

* D release implementation  (arturt, 17:14:36)
  * I recommend that we consider how a stable release can be fully
    packaged with all working dependencies, e.g. for offline deployment,
    as a way to ensure that stable releases don't break due to external
    dependencies that keep changing after OPNFV release. This should be
    an option, if the OPNFV user needs that level of stability.
    (bryan_att, 17:16:47)
  * I think addressing this need will benefit Canonical and OPNFV, as it
    gets closer to the "real-world" deployment goals that I mentioned on
    the OPNFV list. So the effort to make it work (including any
    upstream effects, e.g. on the JuJu and MAAS frameworks) will benefit
    those communities and commercial products based upon them.
    (bryan_att, 17:18:33)

* OPNFV plugtest and plugfest  (arturt, 17:19:17)
  * LINK: https://jujucharms.com/u/debayan-ch/abot-ims-basic/trusty/35
    (arturt, 17:25:05)
  * final note: of course, essential things (e.g. security patches) need
    to get thru this "stable" code firewall, and how that would work
    needs to be considered. In our case it would be that we build the
    system internally and let in any patches through a process of staged
    platform CI/CD.  (bryan_att, 17:25:32)

* Other project  (arturt, 17:26:32)
  * re config files, my input to the Infra call:  there are 3 things -
    the pod descriptor (actual hardware information); scenario use
    intent for the hardware and software settings (e.g. which NICs have
    which role, or the intended VIM settings); as-deployed state
    (including additonal VIM settings that were decided by the installer
    or unspecified in the  (bryan_att, 17:44:25)

* JIRA issues review  (arturt, 17:44:33)
  * ... scenario file)  (bryan_att, 17:44:41)
  * log of the Infra meeting:
    http://ircbot.wl.linuxfoundation.org/meetings/opnfv-meeting/2016/opnfv-meeting.2016-11-23-04.31.log.html
    (bryan_att, 17:45:39)



Meeting ended at 15:58:04 UTC.



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

* arturt (15)
* bryan_att (11)
* narindergupta (4)
* collabot` (3)



Generated by `MeetBot`_ 0.1.4