...
- 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 -
Jira server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key OOM-460 - Helm version 2.3 to 2.8? test 2.7 to 2.8 - fully test this - JIRA
Jira server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key OOM-486 - 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 Glozman working on it.
- Michael O'Brien verified 2.7.2 - working now - sent mail for upgrade procedure to community 1830 EST (GMT-5) - https://lists.onap.org/pipermail/onap-discuss/2018-January/007674.html
- (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 Sauvageau 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.
- 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.
- Proposal for Scaling of ONAP components. Milind Jalwadi
- Milind Jalwadi 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.
- Some parameters should maybe populated at run time, e.g. openstack configurations (there will be multiple openstack configs).
- 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?
- Consul health checks
- Some components are not providing standard ways to provide health checks.
- OOM Backlog sanity
- Anything of interest...
...