Agenda:
- Update / Progress
- F Michael O'Brien discussed with the Policy team.
- Policy team using Vagrant
- They need ONAP 1.1.1 to work. Team agreed that making 1.1 working in Kubernetes is the top priority
- 20170814: the 20170810 tagged master is working so far
- DCAE Gen 2 dependency
- AT&T has code available for DCAE gen 2.
- Should be available in a few weeks
- It was agreed that the OOM team will require to make DCAE work on OOM, and then work on DCAEg2 when ready
- Borislav Glozman has committed code for
config management secrets management that is needed for non-Rancher deployment (defect
OOM-3
-
Getting issue details...
STATUS
)
- Commits have been done more than a week ago. Need committers to review and approve
- Mandeep KhindaMike Elliott agreed to review by EOW
- Michael O'Brien has started contributing to the code but is not currently a committer.
- Add to committer list
- 20170814: status - I was able to commit no issue.
OOM-5
-
Getting issue details...
STATUS
in review/merge-conflict fix,
OOM-62
-
Getting issue details...
STATUS
I will use a non-ONAP dockerhub for now.(thanks Mike Elliott)
- TOSCA based orchestration demo
- Arthur Berezin presented concepts
- Cloudify provides a consistent TOSCA model for app deployment
- How does it integrate with Openshift or rancher? Answer: the operator will be allowed to chose options. Provides the flexibility of deployment.
- Team agreed that the deployment mechanism must be a choice for the operator - nothing forced by the OOM platform.
- Q: It seems you are wrapping a 50 lines file in a 500 lines file. Why? A: To provide consistent app descriptors across deployment mechanisms (openstack, bare metal, K8S, etc).
- Need to understand between K8S and Cloudify. Are we preventing K8S to perform its job by adding Cloudify on top? A: Cloudify is decoupled from K8S. We are delegating a portion of the orchestration to K8S. Cloudify is adding value on top of K8S, and letting K8S do what it does best: container orchestration.
- Goal of Cloudify is really to use a TOSCA based approach to deploying applications.
- John Ng presented the AT&T progress on Cloudify
- AT&T needs to bring the code upstream earlier
- M2 functionality freeze
- Next objectives
- Team agreed that making 1.1 working in Kubernetes is the top priority
- Fix the ZOOM meeting for next meeting.
- Arthur Berezin will share blueprint as seed code.
- Need to allow people to push code that is not working
- Team agreed that we should use an Upstream first approach to OOM (got a few +1's on the call on this one). Same concept should be applied to ONAP wide. David Sauvageau to bring issue to TSC tomorrow.
- John Ng will reach out to internal AT&T team members to see how soon the code can be uptreamed. The idea is to make sure we create a community around OOM. We need to avoid 100k commits.
{"serverDuration": 235, "requestCorrelationId": "1e215027861e5d9d"}
1 Comment
Michael O'Brien
20170815: will update morning of 20170815 and then remove this status comment:
Guys,
I have last minute customer meeting from 10-11 tomorrow – as soon as it ends I will jump on the OOM call.
I am in the process of breaking up the large DCAE patch under code-review into what works and what is pending (4 of 10 work (including pgaas), 1 more (ves-collector) should work by tonight, the rest I will need to fix – mostly cdap’s boot script) Since I am no longer blocked by the nexus3 repo (pushing to oomk8s) – they can be run as soon as the commits are approved).
https://jira.onap.org/browse/OOM-5
https://jira.onap.org/browse/OOM-62
/michael