/
OOM Meeting Notes - 2018-01-24

OOM Meeting Notes - 2018-01-24

Owned by Michael O'Brien
Last updated: Jan 24, 2018Version comment
2 min read



Agenda

  • JIRA board https://jira.onap.org/secure/RapidBoard.jspa?rapidView=41&view=planning&selectedIssue=OOM-63&epics=visible

  • @Seshu Kumar Mudiganti from SO - last PTL meeting - would like to discuss scaling and resources - JIRA

  • Reviews https://gerrit.onap.org/r/#/q/status:open+oom

  • OOM-460 configuration work - OOM-460: Segregating configuration of ONAP componentsClosed

  • Helm version 2.3 to 2.8? test 2.7 to 2.8 - fully test this - JIRA OOM-486: HELM upgrade from 2.3 to 2.8.0Closed

  • 1.6.10, 1.8.6k, 2.3x, 1.12d - 1.6.14, 1.8.6, 2.8.(s/c), 1.12d  @Michael O'Brien will test clouds


  • (borislav 2.6.2 testest on R 1.6.14 - vnc-portal testing

  • Amsterdam Release notes - OOM still in "experimental mode" for Amsterdam. 

    • When ready, OOM shall create it's own internal release and let the community know. Target EOW.

  • OOM Roadmap @Roger Maitland

    • Persistent volumes: Need to identify which components do not have a good strategy for data persistence and add to OOM backlog, i.e. support restart without loss of data.

      • Please read: Did You Know? and OOM for Production-Grade Deployments for Beijing scope details for OOM.

      • @Borislav Glozman will provide the analysis of the current state of component consistency. @David S to add to backlog.

      • Identify special requirements/constraints such as "multiple instances of mariadb shall not share the same inode". The OOM team should drive this. 

        • Create a wiki page to identify this, @Jerome Doucerain to create initial list.

  • Proposal for Scaling of ONAP components. @Milind Jalwadi (Unlicensed)

    • @Milind Jalwadi (Unlicensed) bringing the idea of centralizing ONAP component scaling parameters.

    • Current design proposing helm dependency injection for all configuration management / parameters including scaling

    • OOM should start gathering requirements for each component so that we show how that can be done in OOM. 

      • Create a structure in the wiki, advertise in mailing list.

      • OOM team members should join all component project teams and describe the work required to support scaling in OOM.

    • Are we focused on dynamic scaling, manual scaling or both?

      • Make sure we refine the target for Beijing vs Casablanca.

      • Which tool is used for threshold setting? 

        • For manual scaling, probably in helm

        • For auto-scaling, need to involve the component teams to figure out how K8S can be used to scale each of the components,

          • teams are looking for guidance, 

          • Split the work across many team members here. 

  • Update on config management @Mike Elliott

    •  Some parameters should maybe populated at run time, e.g. openstack configurations (there will be multiple openstack configs). 

      • This is an SO + AAI requirement more than an OOM requirement. Should be brought to the ARCH sub-committee. @Yury Novitsky to bring the issue to the discuss list.

  • @Pavan Gupta faced issues installing ONAP Amsterdam from OOM. Recommendation: use Master, was tested on CI/CD to be working. @Michael O'Brien - (deprecated as of 20170508) - use obrienlabs and @Alexis de Talhouët to support if required

  • Question / Technical issue: Should MSB discover services automatically? 

    • In Amsterdam, need to manually provide the Token. On master this is done automatically. 

    • OOM defect will be opened and discuss list conversation will be started. @Hong Guan and @jh245g@att.com

  • Consul health checks

    • Some components are not providing standard ways to provide health checks. 

  • OOM Backlog sanity

  • Anything of interest...

@Michael O'Brien to update the new sprint JIRA board

Notes