Agree with Tina. We should avoid pure integration community problem. BR Bill Ren -----邮件原件----- 发件人: main@... [mailto:main@...] 代表 Tapio

Again: Being an integration project doesn't preclude doing development at all! It's simply a question of clarifying the primary mission. If people feel Akraino's main mission is development like in

The current code is only the seed code that AT&T generously donated to kick-start the project. Obviously there are pieces missing and maybe pieces we may not need / want to do differently later. I

Hi all, Thanks for the lively discussion! Link to my slides is

I agree with Tina, my assumption has been that Akraino does both integration (blueprints) and development ("horizontal projects"). OPNFV seems to have an image problem in that it is seen to be only

Dear Srini et al, Good questions. In my mind, Akraino is Integration + Development project. Thank you, Tina On Sep 6, 2018, at 3:02 PM, Srini <srinivasa.r.addepalli@...> wrote: IMPORTANT NOTICE: The

Hi, Few more thoughts. I guess we are all trying to see the scope of AkrainoJ. It is my mental picture that integration project involves not only deployment, but also building images. But as

Hi All, Please find attached the material discussed today for your reference. Andrew

I used mid-stream following the example of OPNFV without intentions on going into details on history. I asked the question just to see where we stand today and to get a better picture on the

This may initially be an integration project like OPNFV – but not clear long term this is what we all agree on. I feel like OPNFV debate all over again. The reason why OPNFV turned into integration

The approach of a Specification within a given Blueprint to fully define a POD aims to allow the example you mentioned i.e. the addition of a server without changing the blueprint. One way or

Thank you for discussion on this. Terminology suggested by Wenjing on categorization (features/functional and integration) seems good to me too. Thanks Srini

Hi, I like to comment on the example “5G use case”, suggesting multiple deployments (thus multiple blueprints) depending on number of servers etc. I must say I don’t love the implied

It is confusing, yes. And it confirms that we've not made explicit whether Akraino is mainly an integration, development, or specification/standardization project. I hope we can agree that Akraino is

I like the functional blueprint description which can focus on ‘features’ and the integration blueprint which focuses on the ‘funcitions/modules’ which will be integrated together. I don’t

Thanks Andrew, Srini, We will certainly need something like the concept of a Blueprint Specification to address variants of a common general blueprint where a certain OS, CPU Arch,

Yes, thank you Wenjing That is what I was referring to – I think an integration project and a functional project are very different and the blueprints for each would be substantially different

Agree we should not call “feature development” projects Blueprints. The terms ‘Feature Project’ and ‘Blueprint’ seem sufficiently distinct and descriptive to me Andrew

Glenn, I think you were referring to: - feature project - integration project (close to what Akraino calls blueprint) as used in opnfv. That was my proposal, if we could convince everyone the use of

>>Responses below – this gets to the key definition what a “Blueprint” is and how it can be tailored and evolve.