Oliver,
About integration environment, I totally understand how helpful having a
integration environment applied for debugging and testing code during
developing. I should say it was also my dream having a integration environment
before I write code when I was a developer. But my boss never provided such
costly convenience to me. I have to write test code for unit test and use test
tools for integration test during developing. The integrated environment only
provided for final integration test. I believe most open source practice is
same with our internal developing in this case. The draft roadmap of ONAP first
release on wiki shows Test Lab Ready on middle of September, just before R0. So
my understanding is developing team should use test tools simulating real E2E
environment during developing. Deadline of test lab is mid-September not June
29.
We will provide commercial vNFs with limited license(like only supporting 5 to
10 end user) and limited time (like expired after one year) for integrated
testing. Either Ericsson or Huawei can touch these vNFs in ONAP test lab like
we have already done in OPEN-O test lab. We are not worry about being stolen of
a binary vNF while we are keeping upgrading this vNF.
We have three use cases for different purpose. Some operators are interested in
vCPE while mobile operators regard core network as key requirement for a MANO
system and developers might prefer simple vFW deployed in Rackspace cloud. I
agree that all tests should be repeatable in more than one test lab. How many
test labs and how to run these test labs for three use cases would be discussed
in integration project.
Best Regards,
Yuan Yue
袁越 yuanyue
资深战略规划师 Senior Strategy Planner
技术规划部/技术规划部/系统产品 Technology Planning Dept./Technology Planning Dept./System
Product
南京市雨花区软件大道50号中兴通讯3号楼1/F,Building 3, ZTE Nanjing R&D Center II, No.50, Software
Avenue,YuHua District,Nanjing,P.R.China 210012
T: +025 88013478
M: +86 13851446442
E: [email protected]
www.zte.com.cn
原始邮件
发件人： ＜[email protected]＞
收件人：袁越10008526
抄送人： ＜[email protected]＞
日 期 ：2017年05月17日 20:57
主 题 ：Re: [onap-tsc] Thoughts on next steps.
Yuan,
let me separate things a bit.
The way I look at it is that there is a set of use cases which gate the success
of the release. Those use cases have a set of VNFs.
I completely agree with you that ONAP should support many commercial VNFs. In
fact I would like all commercial VNFs to be supported by ONAP that’s the
ultimate goal of AT&T, however, that does not mean that all of them have to be
part of the set of VNFs used for the use case which gates the release.
Now let’s focus on the VNFs which gate the release as the others can be worked
using proprietary or bilateral agreements. As stated below I don’t know how to
do that efficiently. That doesn’t mean there isn’t a solution. So if you can
outline one that would be great. I see three main challenges:
1. Developer access to VNFs. From experience you can speed up development
substantially if you give developers access to an integration environment. It’s
nice to develop against specs but I have never seen a complex project (inside
or outside of AT&T) which just worked based on developers working against
specs. That’s where the whole agile idea comes from. Integration testing
becomes an integral part of your development. So one way of fixing this is to
give access to an IST level environment to the developers. That’s the approach
we took with open sourcing ECOMP. Without that our demo use case would probably
still not be working. So now if we use a commercial VNF how do we get
developers these environments? E.g. AT&T has multiple development teams and we
dynamically provided them what they needed on Rackspace to open source ECOMP.
There are two solutions to this in my mind:
a.) We have a shared lab where all developers perform all the IST testing. If
we want to follow this approach we have to answer the following questions:
Considering the substantially larger scale then Open-O do we have a lab that
can support ALL developers by 6/29? Who would provide that? Does the shared
lab really have enough instances to not slow development down?
Does that lab have a license which would allow them to give first hand access
to e.g. an Ericsson (sorry just picked somebody randomly for illustrative
purposes) developer to a Huawei or ZTE VNF?
Would e.g. Ericsson allow there developers to access that VNF or would they be
afraid of IP entanglement if they did?
Do we have to worry about any international export control or anti trust laws
doing this?
Again all those questions need to be answered by 6/29 to make this work for the
first release and I have seen little discussion on this so far.
b.) Each organization developing provides it’s own integrated testing
environment to it’s developers. That would mean e.g. AT&T needs to run all
those VNFs in it’s own internal lab. Of course AT&T wouldn’t pay for that after
all we are providing free code to the community so we wouldn’t pay license fees
to a vendor to do so.
In this case are the VNF vendors willing to license there VNFs to ALL ONAP
contributors for free in support of ONAP development?
Are those license agreements reasonable enough (e.g. limited indemnification if
software gets stolen) for the ONAP development teams to actually sign?
Can all of this be completed by 6/29?
2. Another problem is around final acceptance testing of the release. I am a
strong believer that if others can’t repeat something it doesn’t really exists.
E.g. in physics a phenomena is only true if more then one DIVERSE team was able
to observe it. I strongly believe software testing needs to follow the same
objective. So how would we set up repeatable testing of commercial VNFs which
can be performed by more then one diverse team? The possible approaches are
similar then the once outlined above.
3. The last one is around demos. E.g. one things which I think has been fairly
well received (based on the feedback I got) is the fact that you can try the
ECOMP part of ONAP on Rackspace EASILY. I know we are still working on the
generic open stack setup but the fact that so many people are asking for it is
an indication that people want to “kick the tiers” of ONAP in there own
environment. Again how would we address this need with proprietary VNFs?
Without delivering VNFs with the use case ONAP is just a huge amount of code
doing nothing …. . Or to put it differently. A wise man told me once: “ People
don’t want platforms they want solutions!” if we can’t demo a solution as part
of the release openly people will be very disappointed.
Again I don’t see a practical way of addressing this in the time given (e.g. I
know for example that even a free license agreement with AT&T generally
requires negotiations in the risk and IP area). If you know one could you
please outline it so the community can understand what the plan is in detail?
Thx
Oliver
＞ On May 17, 2017, at 3:27 AM EDT, [email protected] wrote:
＞
＞ Hi Oliver and all,
＞
＞
＞
＞ My answer to " I wouldn’t even know how that worked in practice. E.g. will
those VNFs be available to competing vendors so they can test/develop ONAP
code?"
＞
＞
＞
＞ We have already finished VoLTE testing in Open-O project with vIMS and vEPC
comes from Huawei, ZTE and Ericsson. There was no problem using this
proprietary vNFs for testing in Open-O. We also commit in ONAP community ZTE
will provide our vNF packages with limited license for testing purpose.
＞
＞ Deploying and managing vendor vNFs brings practical value to ONAP community.
Anyway, target of ONAP project should be deploying and managing more commercial
vNFs. I believe vNFs from companies other than ZTE and Huawei are also
welcome for the VoLTE usecase.
＞
＞
＞
＞ Best Regards,
＞
＞ Yuan Yue
＞
＞
＞
＞ 袁越 yuanyue
＞
＞ 资深战略规划师 Senior Strategy Planner
＞
＞ 技术规划部/技术规划部/系统产品 Technology Planning Dept./Technology Planning Dept./System
Product
＞
＞
＞
＞
＞ ＜9ae3e214c17d49ed935d87c674ba3ee2.jpg＞
＜24242e5637af428891c4db731e7765ad.jpg＞
＞ 南京市雨花区软件大道50号中兴通讯3号楼
＞ 1/F,Building 3, ZTE Nanjing R&D Center II, No.50, Software Avenue,YuHua
District,Nanjing,P.R.China 210012
＞ T: +025 88013478
＞ M: +86 13851446442
＞ E: [email protected]
＞ www.zte.com.cn
＞ 原始邮件
＞ 发件人： ＜[email protected]＞
＞ 收件人： ＜[email protected]＞
＞ 日 期 ：2017年05月17日 03:47
＞ 主 题 ：[onap-tsc] Thoughts on next steps.
＞
＞
＞
＞ I just went through the proposals and noticed that quite a few of them have
not clearly defined boundaries between them which makes me wonder if they
overlap (see table below). From experience overlapping project definitions
rarely lead to good outcomes (duplicate work gets done and people are very
upset at the end…) so I think we should resolve this before approving the
projects.
＞
＞ When I built this table I focused on what’s written in the proposals. Now
from discussions I think some of the perceived overlaps might just be a matter
of cleaning up the writing. Others might actually be real. In either case I
think we need to be clear and precise in the project description and can’t
rely on various email exchanges for this. I also don’t claim that my table is
complete. If you want I can put the table on the Wiki so people can add there
perceived or real overlaps.
＞
＞ I don’t know how you usually resolve those issues but I would think that the
project leads for all projects which might have an overlap define a common
statement which defines there relationship with each other in some level of
detail. Thoughts?
＞
＞ I also looked at the use cases. Lingli and her team did a great job cleaning
up the VoLTE use case:
＞
＞ https://wiki.onap.org/pages/viewpage.action?pageId=3246140
＞
＞ The flow charts are a great start but we do need to get into more details and
actually show the real API calls as well. I am also not sure I understand how
exactly the legacy Open-O and legacy ECOMP components integrate. I think the
next step here is to walk through this in detail. I don’t think that’s
something that can be done efficiently via email. I would suggest a call on the
topic. That might actually be better then a F2F in June as it allows more
developers to dial in.
＞
＞ One concern on this particular use case is that only Huawei and ZTE have any
VNFs in it. Personally I don’t think it’s a good start for an open project to
start with proprietary VNFs from mainly one manufacturer with some contribution
from a second. I wouldn’t even know how that worked in practice. E.g. will
those VNFs be available to competing vendors so they can test/develop ONAP code?
＞
＞ This brings me to overall use case scope and reality.
＞
＞ Using Gilda’s release plan (all his fault after all :)) we have to work all
of this out by 6/29 (sounds a lot of time but really isn’t). Development is
only 3 months till RC0. We have 32 projects. That’s 21 projects more then the
seed code of 8+3. If I ignore the toy use case we have two use cases proposed
with the VoLTE one having more details then the other. Coordinating interfaces
one on one for the 32 projects requires 512 meetings. …. I think if we are
trying to achieve all of this in release 1 we are setting ourselves up for
failure.
＞
＞ If it was up to me I would probably just focus the use cases on instantiation
and one simple control loop. This might seem like very little but considering
the work we need to start the projects, set up the labs, get developers
familiar with the environment, get them lab access etc… which all takes time.
I think that would be realistic for a first release and then we can adjust the
second release accordingly.
＞
＞ In terms of projects I would be very careful which projects have
deliverables in release 1.0. . I don’t think having deliverable in release 1.0
is a gating function of getting a project approved. So the TSC can approve
projects that make sense but as said I would discourage some of them to have a
contribution to the 1.0 release.
＞
＞
＞ Probably just stating the obvious … .
＞
＞ Oliver
＞
＞
＞
＞
＞
＞ Project Potential Scope Overlapp
＞ AAI
＞ APPC Common Controller… , VF-C
＞ Authentication…
＞ CLAMP Modeling
＞ Common Controller … VF-C, App-C, SDN-C, ONAP Operations Manager,
Microservice Bus, DCAE, DMAAP, MultiVIM, Service Orchestration
＞ DCAE Holmes, Common Controller…, DMAAP
＞ DMAAP Common Controller… , DCAE (mentions data processing)
＞ Documentation ONAP University
＞ External API Framework Modeling, External System Register, ONAP
Extensibility
＞ External System Register External API Framework, ONAP Extensibility
＞ Holmes DCAE
＞ ICE VNF-SDK
＞ Integration ONAP Operations Manager
＞ Microservice Bus Common Controller …, ONAP Operations Manager
＞ Modeling CLAMP
＞ Miulti Vim Common Controller…
＞ Network Function Change..
＞ ONAP CLI
＞ ONAP Extensibility ONAP Operations Manager, External API Framework,
External System Register
＞ ONAP University Documentation
＞ ONAP Operations Manager Common Controller… , Integration, Onap
Extensibility
＞ ONAP Usecase UI Project
＞ Policy Driven VNF Orchestartion Policy Framework, SNIRO
＞ Policy Framework… Policy Driven VNF Orchestration
＞ Portal Platform …
＞ SDN-C Common Controller…
＞ Service Design & Creation Modeling
＞ Service Orchestration Common Controller…
＞ SNIRO Policy Driven VNF Orchestration
＞ VF-C Common Controller… , App-C
＞ VID
＞ VNF-SDK ICE
＞
＞
＞
＞
_______________________________________________
ONAP-TSC mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-tsc
