Re: Akraino Charter

Margaret Chiosi <margaret.chiosi1@...>

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 think we need any more granular splits than these.


Thank You,

Margaret Chiosi

VP Open Ecosystem Team


Admin: Sophie Johnson


+1 (908) 541-3590


Futurewei Technologies, Inc.

Fixed Network Solution CC

400 Crossing Blvd

Bridgewater, NJ 08807

(cell) +1-732-216-5507



From: main@... [mailto:main@...] On Behalf Of Andrew Wilkinson
Sent: Wednesday, September 05, 2018 6:42 PM
To: main@...
Subject: Re: [akraino] Akraino Charter


Agree we should not call “feature development” projects Blueprints.


The terms ‘Feature Project’ and ‘Blueprint’ seem sufficiently distinct and descriptive to me




From: main@... <main@...> On Behalf Of Wenjing Chu
Sent: Wednesday, September 05, 2018 3:09 PM
To: main@...
Subject: Re: [akraino] Akraino Charter



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 the terms.

I personally agree with you that “project “ is a more general term, and the work of building a blueprint is a special type of project. But I’m flexible in naming itself.


From: Glenn Seiler

To: main<main@...>

Subject: Re: [akraino] Akraino Charter

Time: 2018-09-05 14:03:18


I don’t love the idea of using the term BluePrint for the functional development projects.

I think the term is already overloaded enough, and there is already some confusion between the term blueprint as it applies to OpenStack and an Akraino Integration blueprint.


I like the term blueprint as it applies to things are being ‘built’ or integrated from multiple sources, with potentially multiple regulations  (or standards) to apply and potentially with very different components (HW, VIM, MW or APIs) etc.   Using the same term to apply to a more focused and singular project may be pretty confusing.


Perhaps we could do something more consistent with what OPNFV is doing? Using project proposals/plans to define and propose new functional projects.






From: main@... [mailto:main@...] On Behalf Of Wenjing Chu
Sent: Wednesday, September 05, 2018 11:04 AM
To: main@...
Subject: Re: [akraino] Akraino Charter


Visibility is the same whether we call it project or blueprint. I’m fine with either name.

Do note that if blueprint A and blueprint B share a component developed within Akraino, we will then need to create another blueprint C, as you suggested, and A and B would have dependency on C.

The key point here that Srini brought up is that we explicitly state that functionality development is in scope for Akraino.


From: Thomas Nadeau

To: main<main@...>

Subject: Re: [akraino] Akraino Charter

Time: 2018-09-05 08:00:05


The idea for doing everything in blueprints is that it brings visibility into any work that impacts the project to both the TSC, but also clearly in writing so any others (i.e.: integration, testing, etc...) that might be external to the project have clear information about what is planned or underway.  On a related note, I view blue prints as being largely analogous to epics, and in the same way are a good way to plan for a current or future release, and just a good way to organize the moving parts of a large project like this one potentially can turn out to be.




On Tue, Sep 4, 2018 at 7:30 PM Wenjing Chu <Wenjing.Chu@...> wrote:

As long as we agree that such work should take place in Akraino, then it’s just naming. Yes, we could have a “non-integration blueprint”, but it seems really confusing to me.




From: main@... [mailto:main@...] On Behalf Of Thomas Nadeau
Sent: Tuesday, September 04, 2018 1:34 PM
To: main@...
Subject: Re: [akraino] Akraino Charter



On Tue, Sep 4, 2018 at 2:47 PM Wenjing Chu <Wenjing.Chu@...> wrote:

Very good point. We do need to clarify this as soon as possible.


In the initial draft on blueprints, I proposed that we (a) use “project” as a unit for all the development work in Akraino, and (b) categorize projects into 2 types: functional projects and blueprint integration projects. (b) is similar to what Kandan called “vertical” and “horizontal”, but uses terms closer to those in other communities.


-        Functional projects develop functionalities to fill identified gaps.


Why wouldn't you do a blueprint for those too - perhaps a shorter blue print?  




-        Integration projects are responsible to deliver end-to-end ‘blueprints’. Integration projects can utilize the outputs of functional projects, and all upstream open source projects.




From: main@... [mailto:main@...] On Behalf Of Srini
Sent: Tuesday, September 04, 2018 9:50 AM
To: main@...
Subject: [akraino] Akraino Charter


Hi Akraino TSC,


In the last developer conference, TSC has taken an AI to come out with the Akraino charter definition.

Much of the discussion on last developer conference is mostly about blueprints, except for one break-out session.


In regional orchestration, Edge API and AI breakout session, we talked about the need for them and the consensus is that Akraino project is the right place to develop them.  In one of the Kandan’s presentation, it was clear that Akraino is not only for developing blueprints for various use cases, but is also a home for Edge related open source projects for the functionality where there is a gap in the open source community. Please consider making the Akraino charter clear on the aspect of development projects to avoid any confusion.







Join to automatically receive all group messages.