ID
| JIRA / helpdesk #
(if applicable) | Team Blocked | Blocked by | Team that needs to Respond | Notes | M2 Blocking | Resolved Y/N |
|
|
|---|
B1 |
| VoLTE usecase/ Integration/CLAMP/Holmes | Identify the story of fault correlation and auto-healing. | VFC | Which VNF, what kind of fault, etc.
Needed for M2 integration test case design -by 7/30
Feedback from CMCC: is talking with vendor to check the capabilities of VNF event generation. Should provide answer by 8/3
| Y | Y VoLTE Use Case Control Loop |
|
|
B2 |
| VF-C | VES Collector API,nfc/nfnaming standard | DCAE | DCAE R1 Release Planning#APIOutgoingDependencies
8/21 - Vijay Venkatesh Kumar: The nfc/nf namingconvention is being worked with A&AI team by Alok Gupta. For DCAE this information is pass-through (as VES spec identifies these as optional parameter)
8/22 Thanks Vijay Venkatesh Kumar, Currently the nfc/nf name field from VF-C side?we will fill the values with an empty string.
|
| Y |
|
|
B3 |
| Holmes | Code: message get from and back to DMaaP | DCAE | Need the sample to learn how to get message from and back to DMaaP. |
| Y The test script for interfacing with DMaaP Message Router can be found at "git clone http://gerrit.onap.org/r/dcae/demo/startup/message-router", then look into docker_files/tests/test.sh. |
|
|
B5 |
| Holmes and VF-C | DMaaP API: sub/pub, query, etc. | DmaaP | Pamela Dragosh: If Ramprasad Koya or Varun Gudisena could provide a wiki page or documentation for this API that would be great. Both the Holmes and VFC team need to know the work involved in integrating this.
Feedback from Varun, the API documentation for DMaap will be availabe by August 3rd.
Feed back from Yan, VF-C will not depend on DMaap in R1.
|
| Y API Documentation is available at DMaaP API
|
|
|
B6 |
| Policy | VF-C API invoked by Policy | VF-C | Pamela Dragosh: The policy team requests that VF-C use the Dmaap API that is identical to what APPC supports today. Having a common Controller API would be ideal.
Feedback from Yan, VF-C are working on the rest API that provide to policy,the rest API plan to be available by August 3rd.While VF-C team are analyzing the Dmaap API to decide whether to use DMaap or not in R1,
Feedback from Yan,VF-C has provided the rest API to Policy Team.
|
| Y |
|
|
B7 |
| Holmes | Holmes component spec., DMaaP topic + message, rules, etc. | Holmes | To work with the control loop, Holmes needt o do a lot of work.
Guangrong Fu: the component-spec file has been sent to the DCAE team. Waiting for the response.
Guangrong Fu: A sample rule could be found at Holmes Weekly Meeting (20170720)
|
| Y |
|
|
B8 |
| vCPEuse case/Integration | To confirm the interface between SDC and CLAMP | SDC/CLAMP/DCAE | SDC, CLAMP, DCAE have confirmed that the interfaces among them for closed loop control have been defined, implemented, and tested. |
| Y
|
|
|
B9 |
| vCPE use case/Integration | To confirm the vCPE service model are fully supported by SDC. | SDC | The vCPE team has called a meeting on 7/27 to address this.
Michael Lando: the vnfs for vcpe were successfully onboarded and distributed .
there is no issue from the SDC side.
|
|
|
| Y |
B10 |
| VoLTE usecase/Integration | Confirm if SDC can import TOSCA template and view/edit the template | SDC | Feedback: The answer got during July virtual developer event was SDC supports TOSCA, but need to check if VoLTE template from Open-O (that's what VFC is expecting) can be supported.
Michael Lando sdc is working on the needed capabelties to support the import.
|
|
|
| N |
B11 |
| MSB | A repo under OOM to accommodate the registrator codes which integrate OOM and MSB
Resources and Repositories (Deprecated)#ONAPOperationManager
| OOM | Request has been sent out to OOM PTL but no response yet. |
|
|
| Y |
B12 |
| SDC | The work flow repo | SDC | During the virtual developer meeting, Michael response that he will take care of it.
Michael Lando: the repository is avilable and the work flow code is there already
|
|
|
| Y |
B13 |
| Holmes | Holmes is not able to call A&AI RESTful APIs while integrated with DCAE.
| MSB/OOM/DCAE | Need DCAE to be integrated with MSB for service discovery. |
| Y |
|
|
B14 |
| VoLTE usecase/ Integration/SO/VFC | SDC VoLTE use case support | SDC | Identify the gaps before the functional freeze milestone, here are the action items and date.
Design an example VoLTE model with SDC and export the model as CSAR (use OPEN-O VoLTE CSARs as reference) – by July 30
Analyze the gaps for VoLTE model design supporting – by July 31
Estimate the Identified gaps and risks, decide which plan should be the first priority to support VoLTE use case in Amsterdam release. - by August 1.
Add the work items to Amsterdam Release to address all the identified gaps. - by August 3.
| Y | Y |
|
|
B15 |
| SDC/VFC integration | VoLTE usecase support | SDC | NSD and NS Package need
the SDC team confirmVNF Package and ImageDesc need the SDC team confirmTOSCA issues need the SDC team confirm
Michael Lando SDC is looking into the issues .
|
|
|
|
|
B16 |
| VNF SDK | Need to understand process for handing-off TOSCA packaged VNFs for onboarding | SDC | Need to understand how we can transfer VNFs from the vnfsdk package validation tool to SDC once the VNFs have been validated | N | Y |
|
|
B17 |
| VF-C | VoLTE usecase related instances persistence
Need to confirm if adding new attributes will impact other projects
| A&AI | James Forsyth will provide instructions for adding new attributes that used in VoLTE usecase in A&AI scheme. Complete - see this page: Tutorial: Making and Testing a Schema Change in A&AI
|
| Y |
|
|
B18 |
| SO | VFC NBI definition for SO | VFC | Need VFC NBI definition
-by 7/31
Feedback from Yan, VF-C team have discussed the interface with so team and will provide the interface document by 7/31
Feedback from Yan,The interface document has uploaded in wiki:
VF-C R1 Deliverables
|
| Y |
|
|
B19 |
| SO | Clearly define and document SDC output and its content, including recipe, model, and other artifacts | SDC
| Michael Lando sdc has documented all the external api and destribution info.
please remove thsi blocker or spcify what exactly is needed.
| N | N |
| N
This is an issue not a blocker.
|
B20 |
| Multi VIM/Cloud | ARIA flow interfaces for Multi VIM | SO | Need to identify basic scope for R1 and function test case |
|
|
| Y |
B21 |
| Multi VIM/Cloud | APP-C interfaces for Multi VIM, Should we support VM status get, stop, start for R1 use cases? | APP-C | Need to identify API for R1 and function test case for VCPE use case |
|
|
| Y |
B22 |
| Multi VIM/Cloud | scope for R1 | DCAE | identify DCAE service delopyment interfaces for Multi VIM, interfaces called by Cloudify |
|
|
| Y |
B23 |
| APPC | Dependency on SDNC for ODL Docker | SDNC | APPC is dependent on SDNC for the ODL and must align on same version. SDNC is planning to upgrade to Carbon, so APPC must also upgrade. ETA for Carbon Docker was end of July, but reforecast to 8/4. ODL upgrade has been problematic in the past, so important to get this as soon as possible to start integration. | N | N | Received Carbon ODL Docker from CCSDK; working to integrate into APPC now. | Y |
B25 |
| DCAE | Need DMaaP deployment blueprint for ONAP R1 | DMaaP | 8/23 - OOM will be deploying dmaap; no longer blocker for DCAE |
|
|
| Y |
B26 |
| DCAE | Need to understand how API endpoints provided by other ONAP components are configured/communicated to when ONAP is deployed. For example, how would DCAE know where is the A&AI API. Is this well-know via a DNS C-name or via service discovery. If the latter, how. | Integration or OOM | Pending decision from Integration team meeting planned for 8/28
Feedback: have scheduled a meeting on 8/7 to discuss the issue.
|
|
|
| N
Results from 8/7 meeting: when ONAP is deployed by HEAT, the service discovery is clear. When ONAP is deployed by OOM, it needs more discussion.
In another meeting which OOM/DCAE/MSB/Integration teams participated, no conclusion could be made on how MSB integrated with OOM.
|
B27 |
| DCAE | Need to understand how the whole ONAP system is brought up, and how various per-deployment configuration parameters are communicated to individual ONAP components and subcomponents. | Integration or OOM | Pending decision from Integration team meeting planned for 8/28
Feedback: have scheduled a meeting on 8/7 to discuss the issue
|
|
|
| N
Results from 8/7 meeting: when ONAP is deployed by HEAT, the mechanism of parameter passing is clear. When ONAP is deployed by OOM, it needs more discussion.
|
B28 |
| Usecase UI | APIs for alarm and performance. | DCAE | Does DCAE provide alarm and performance datas to Usecase UI by RESTful APIs?
08/21 - Vijay Venkatesh Kumar Based on meeting held on 8/14, DCAE events will be subscribed from DMAAAP by usecaseUI team.
| Y N |
|
| N |
B29 |
| CLAMP | Interface content change
DCAE blueprint model needed (Holmes blueprint)
| Policy, DCAE, SDC | 3 potential changes might affect CLAMP development :
the content that Clamp sends to Policy might be updated (api will be the same, only changes in the content); fixedthe format of the blueprint that Clamp sends to SDC might be updated (api will be the same, only changes in the content);the data model for TCA might be changed (means both UI and backend code change)
| N | N | CLAMP team will account for these changes in next sprints but the sooner the change is identified the better. | N
|
B31 |
| OOM | Availability of stable code / docker image for:
SO (currently the MSO code is there, but no tosca-based orchestration added)DCAE Gen 2
| SO
DCAE
| OOM needs to have stable and working docker images in order to complete deployment specs. |
|
|
|
|
B4 |
| Holmes | APIs for service query (like the info of services which are registered to the DCAE Consul) and configuration loading, etc. | DCAE | How to get the external IP of the services via Consul? Where and how to pull the rules designed during the run time? When will the detailed APIs be provided?
Feedback from Lusheng, the high level API will be provided by M2, and the full API spec. by M3.
8/21 - Vijay Venkatesh Kumar: Holmes when deployed by DCAEGEN2 will be registered into Consul by the platform. Run-time rules will be pushed into container as updated configuration (K-V pair)
| N | Y | 2017/08/27 |
|
B33 |
| DCAE/Holmes/POLICY | Clarification on A&AI API calls during Control Loop runtime by the various components. | A&AI
James Forsyth
| Pamela Dragosh will provide more details for this blocking issue.
| N | N | M4 Blocking
Pamela Dragosh will create a wiki to clarify the outstanding issues.
Schedule subsequent meeting with the teams to resolve.
| Y |
B32 |
| VNFRQTS | Jenkins / Verify | LF +
documentation manages the jenkins task for all documentation
| Difficult for the VNFRQTS project to progress unless we can have visibility of our work product at onap.readthedocs.io | Y | Y | working with LF + Docs to resolve | N |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
10 Comments
Vijay Venkatesh Kumar
Yuan Liu - Regarding #3, the Collector API structure is documented here under outgoing dependencies - DCAE R1 Release Planning#APIOutgoingDependencies (this is based on VES standard specification). An example from OpenECOMP - the api exposed was http://10.0.4.102:8080/eventListener/v3 .
Yuan Liu
Thanks Vijay. Do you know where we can find the nfc/nf naming standard, which related to the Common Event Header of VES.
Varun Gudisena
Pamela Dragosh : We are preparing the API documentation for DMaaP. It will be available by August 3rd.
Randa Maher
MultiVIM team,
From an APPC perspective, we need the items identified as Priority 1 in the attached file to support the vCPE use case at a minimum. Ideally, we would like Priority 2 items in addition to be able to test some of the other capabilities of APPC, but we will continue to use CDP-PAL as the fallback plan. The attached document is still in-progress, CDP-PAL team needs to map to OpenStack, but should provide good visibility on what's needed for R1. AppC_CDP_PAL_Multivim_Openstack_API_Mapping-v1.xlsx
Lusheng Ji
Response to B2 B4 B13. For components deployed by DCAE, their service APIs will be published onto DCAE Consul. Details of the API for fetching such info is to be available. For components not deployed through DCAE, see B26.
Lusheng Ji
Response to B3: the test script for interfacing with DMaaP Message Router can be found at "git clone http://gerrit.onap.org/r/dcae/demo/startup/message-router", then look into docker_files/tests/test.sh. For more detailed API specification will need the help from the DMaaP project.
Gildas Lanilis
Randa Maher is B23 a blocker for M3?
Randa Maher
Hi Gildas,
No, not blocking. I updated the table. The ODL docker is now available and we are working to integrate updated version.
Gildas Lanilis
xinhuili are B20, B21, B22 blockers for M3?
xinhuili
Thanks, Gildas. I have updated the status there