Re: Akraino Charter

Georg Kunz
 

Hi all,

 

Following up on Margaret’s a very good point here: assuming that (for whatever reasons) OPNFV was not able to attract enough developers in the long run, I am wondering if creating a second community with a very similar objective does not stretch resources even further – again, in the long run, i.e. after an initial phase of high attention.

 

It needs to be clearly defined if Akraino shall be an evolution of OPNFV or not (and then be honest about it). In any case, following this discussion, there is a huge overlap in the objectives of both communities, so it is fundamentally important to *jointly* i) consider lessons learned, ii) build on top of what has successfully been established, and iii) discuss gaps and how to close them and where.

 

Best regards

Georg

 

 

From: main@... <main@...> On Behalf Of Margaret Chiosi
Sent: Thursday, September 6, 2018 5:37 PM
To: main@...
Subject: Re: [akraino] Akraino Charter

 

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 is because we could NOT attract enough developers.

If we have the same challenge here (we need to be honest with ourselves) – then we should just then realize it will only be integration. If so, then we should take our learning on OPNFV to build akraino charter, labs, etc.

Or maybe just build on OPNFV labs.

 

Thank You,

Margaret Chiosi

VP Open Ecosystem Team

 

Admin: Sophie Johnson

Sophie.johnson1@...

+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 fzdarsky@...
Sent: Thursday, September 06, 2018 9:33 AM
To: main@...
Subject: Re: [akraino] Akraino Charter

 

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 an *integration project*, whose mission it is (paraphrasing from Charter) to make it easier for our users to design/customize, build, and operate edge stacks for their given use case.

And no, this does not exclude us doing software development, e.g. testing tools&frameworks, adding auxiliary functionality for which no suitable upstream exists yet, etc.

And no, this does not exclude us doing specifications, e.g. of Edge APIs where no suitable APIs exist yet.

All it says is that such software development and specification work would be subordinate to the goal of enabling integration.

 

Secondly, I hope we can further agree that Akraino's goal is to *enable* integration, *not prescribe* a given integration.

Means, if our goal is to enable Akraino users to build an edge stack for Industrial IoT, Network Access Edge, etc., we'll ensure that the upstream components have the required functionality for those use cases and that this functionality also works end-to-end to meet those use cases, e.g. CPU resource management or GPU/TPU device management across app, middleware, Kubernetes and OpenStack. Or cross-stack operations.

We are (I hope) not trying to create "Akraino distributions" and spend large amounts of engineering resources on redoing integration, stabilization, hardening, etc. work that's already done by upstream projects and downstream products.

 

In that sense, I kind of disagree with calling Akraino a "mid-stream" project, because that would imply an expectation that downstream products that take source from upstreams like Kubernetes *via* Akraino instead of directly from them... which only makes sense if we envision to fork the upstreams or extend them in ways not acceptable to the upstreams...

 

Thanks,

 

Frank

 

 

On Wed, Sep 5, 2018 at 10:15 PM <ildiko@...> wrote:

Hi,

I got a little confused on one part of the description below. What does “is also a home for Edge related open source projects for the functionality where there is a gap in the open source community” mean exactly?

Is Akraino a mid-stream project meaning that beyond integration and testing it will also identify gaps and work together with other communities to address them in the open source projects? Or saying it is the home for those gaps means that it would be Akraino hosting the code for that missing functionality?

Thanks,
Ildikó


> On 2018. Sep 4., at 11:49, Srini <srinivasa.r.addepalli@...> wrote:
>
> 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.
>
> Thanks
> Srini
>
>
>
>



 

--

Frank Zdarsky | NFV&SDN Technology Strategy, Office of the CTO | Red Hat
e: fzdarsky@... | irc: fzdarsky@freenode | m: +49 175 82 11 64 4

Join main@lists.akraino.org to automatically receive all group messages.