...
Questions need to be answered: Current Mode OPNFV/CNTT RACI Chart
- ollivier:
- Cédric OllivierHow can it help the
- the short term issues? an implementation is needed for the conformance on the VNF side and we need additional relevant resources in both sides: specifications (CNTT) and OPNFV (OPNFV)
- Cédric Ollivier How would be leverage on it in a long term view? We shouldn't reinvent the wheel every release - the current model works and the separation between CNTT and OPNFV is clear for a few main CNTT contributors
- What happens when CNTT develops a requirement in, say, RI-1?
- does CNTT goes directly to prospective OPNFV project and get it implemented (via that project PTL).
- how will the implementation link back to CNTT releases?
- Cédric Ollivier : CNTT RC lists the deliverables (containers/tags/testcases) from OPNFV. What's the additional point here? Could we detail the gap targeted?
- Will each project have their own release cycle (with appropriate baggings) or will OPNFV have an overall release cadence ? how does the model work?
- Cédric Ollivier I think the model works already.
- CNTT is in charge of test case description/selection and playbooks (see RC) and then CNTT selects the test cases from OPNFV according to them.
- OVP should implement the test result verification from the archive produced by CNTT playbook - Compared to first OVP model the test case selection is now in RC
- or will CNTT has to follow some kind of process to get their requirements implemented?
- Cédric Ollivier : we may consider the classical opensource model here and then the answer could be straightforward: by putting developpers
- Cédric Ollivier : opensource cannot follow a subcontractor model by design
- or will OPNFV itself regularly get CNTT releases and find the right OPNFV projects to implement any new requirements.
- via CIRV? Cédric Ollivier: CIRV is mostly an umbrella for incubation projects. It should be done at the project level possibly between CNTT RI/RC leaders and the PTLs/core developpers
- what is the role of OPNFV TSC on all this? who is accountable for what?
- we need to talk about accountability and make it clear who is accountable for what!
- does CNTT goes directly to prospective OPNFV project and get it implemented (via that project PTL).
- How does OVP fit into this matrix?
- Given the GSMA process is it mostly a consumer and ratifier of the output from CNTT, or does it have a role in providing feedback? I.e. how can this be set up to be a two way street?
...
Does it mean that RI-1 would be strictly removed from CNTT repository?
Why Yes why not to consider considering Airship as an implementation amongst others which tries to implement the CNTT requirements (RC is currently rather verified thanks to Functest SUT and Field trials).
I would agree to fully remove RI1 from CNTT but CNTT needs a reference implementation somewhere which passes RC successfully for the next steps (conformance of VNF/CNF).
By the way, it's becoming urgent to take CNTT results into account to find the best path (RI1 doesn't pass RC - we can't leverage on the existing resources allocated to Functest for the VNF conformance)
If FMO targets to improve the process, having an implementation fulfilling CNTT requirements is a very short term key issue
- RC-1 is a test conformance suite
...
Sorry I'm lost here. It's introduced as an executive summary but I would rather consider that it increases so much the complexity both regarding the collaborative work and the end users.
If we target an executive summary it could rather be a minor change in the top CNTT document listing (it could be a new Executive summary bullet in between Governance and Technical specifications)
- RA1 requirements
- additional relevant requirement details (e.g. RA1 chapter 5)
- the related mandatory test cases (please see 3.4 Test Cases Traceability to Requirements)
- RC playbook (please see 4.3 NFVI Testing Cookbook)
RA1 would decide for everything which is not right regarding the current work and false from a collaborative mindset.
I'm lost by considering RI1 as an example. Why should we increase the complexity of RA1 in that case?
If the overall work is about the separation between CNTT and OPNVF, everyone should know that RC1 Baldy and older is only driven by the CNTT part:
- testcase descriptions, selection and integration are part of CNTT RC
- OPNFV implements the test cases and offers the deliverables (e.g. containers) as asked by CNTT (see first bullet)
In my view, Ch 10 is just complexifying the current model which should firstly be demonstrated as false to avoid any sophism as it seems here.
Expand | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
Proposal SummaryIntroduction CNTT was formed in order to create a single spec for Openstack (1-stream) and a single spec for Kubernetes (2-stream). The audience is the end-user companies that will become conformant to these specs. CNTT needs to ensure that the end-user base can easily navigate and consume the documentation. Problem statement In the current CNTT documentation format, CNTT’s end user base will be challenged to figure out what they need to follow in order to be conformant to CNTT requirements and specs – should they follow what’s in RM or RA-1 or both ? Maybe go look in some chapters of RI-1 or RC-1. It’s a bit all over the place right now, hard to navigate. Solution statement Let’s make it easier for the end user to navigate ! Let’s make it easier for the end user to understand what they need to do !
Deeper Detail of the ProposalRA-1 What will the enhanced RA-1 look like ?
RI-1 What will the RI-1 look like based on proposed changes ?
RC-1 What will the RC-1 look like based on proposed changes ?
|
...