I agree with Tina, my assumption has been that Akraino does both integration (blueprints) and development ("horizontal projects").
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 OpenStack, Kubernetes, ONAP, Airship, etc. then let's please make that explicit and - most importantly - clearly define from day 1 what software component/system it will develop. Because it is important that potential contributors and users have the right expectations.
For example, I very much like the way CNCF handles Kubernetes and its satellite projects like Linkerd, Jaeger, Envoy, Prometheus, etc: Those projects are independent from the Kubernetes projects, but they are also highly complementary to it. They have their own release cycle. They are not essential to Kubernetes, but if they prove useful, they'll gain lots of followers and become part of the core Kubernetes ecosystem.
So far, however, we have identified the need for CI/CD and testing and speculated about the possibility of "horizontal components" that may be used by multiple BPs (*have to* be used by all BPs?). Those bits would be essential to the integration, so clearly in scope for an integration project.
Then I've heard speculations that "maybe at some point we'll want to develop an 'edge middleware'". It's not clear to me what and why that would be and why it would have to be done in Akraino. But that's something that could/should be useful beyond the Akraino stack and be an indepdendent yet complementary "satellite" development project around an Akraino integration project.
How about we start of with a clear focus on the integration project and - should a clear need arise later - we consciously re-scope to add such satellite development projects (with independent release cycle and hopefully seeing adoption also independently of the Akraino integration)?
OPNFV seems to have an image problem in that it is seen to be only doing integration. OPNFV has developed a full CI/CD system with functional, performance and verification testing, with a test web page to view all the results. That is something reusable in other contexts also.
What you listed is exactly the software development I would expect in an integration project. I don't know why you think that's an "image problem"? IMO, it's exactly those pieces that are OPNFV's big value to the industry (apart from the gaps it addressed in the upstream projects).
OPNFV has also made a decision not to fork upstream whenever this is possible. We did not want a "Telco OpenStack" in OPNFV, so all work in OpenStack is done upstream and is not visible as OPNFV development (examples are OPNFV Doctor/OpenStack Fenix, OPNFV Apex/OpenStack Triple-O, OPNFV XCI/OpenStack Ansible).
Yes! I believe we should decide the same here!
Where I see that Akraino adds value is
- New hardware platforms, especially the small form factor ones
- Moving beyond NFV to attract new verticals that can benefit from the ecosystem
From: main@... <main@...> on behalf of Tina Tsou <tina.tsou@...>
Sent: Friday, September 7, 2018 6:30:27 AM
Subject: Re: [akraino] Akraino Charter
Dear Srini et al,
In my mind, Akraino is Integration + Development project.
On Sep 6, 2018, at 3:02 PM, Srini <srinivasa.r.addepalli@...<mailto:srinivasa.r.addepalli@...>> wrote:
Few more thoughts. I guess we are all trying to see the scope of Akraino☺.
It is my mental picture that integration project involves not only deployment, but also building images.
But as of now, based on the gerrit repositories in Akraino, it seems that it seems to be deployment project and expects the images are built elsewhere.
OPNFV is complete integration (seems like ☺) project and it works with various types of upstream projects.
- Upstream projects that deliver binaries in various forms (example: Linux images)
o RPMs, debian, docker containers etc…
- Upstream projects that don’t build (needed) binaries : In this case, various OPNFV projects (many, for example Barometer project) has ability to get source code (via git normally), build and make the images in OPNFV repositories.
- Upstream projects with patch projects: In this case, OPNFV projects (e.g Stor4NFV) has ability to get the source code, patch files from various git repos, patch the code and then build them to make binaries.
- Upstream projects with some missing functionality: Some OPNFV projects implemented the missing functionality. This functionality is patched/integrated with upstream projects to create binary images/containers. For example, Barometer project has some collectd plugins, which are not part of upstream collected repos.
OPNFV CI/CD life cycle seems to be complete. In addition to building the images/containers, it also can invoke installers (deployment tools) to deploy the scenarios (images & Day-0 configuration) on Labs and then verify the end-to-end functionality. It is true that these are not production quality as the latest upstream projects may not have been tested thoroughly. Also, the number of test cases may not be sufficient to call it as production quality.
Questions for scope definition:
- Is Akraino look to build the images/containers? Or limit the scope to installers, starting with Airship? If so, which sister project(s) going to build binary images suitable for Airship?
- Is Akraino place to create the patches/enhancements/gaps? There are various opinions and it seems that many like to keep the scope of Akraino simple to make it successful. But, one needs to think about sister projects where these gaps can be filled.
- How does Akraino intend to make the deployment production quality if it does not maintain/create patches for upstream projects?
Based on the answers to above, we should keep the main scope of Akraino either as
- Integration project
- Deployment project (via Airship and others such as compass/apex in future)
- Integration project + feature project.
From: main@...<mailto:main@...> [mailto:main@...] On Behalf Of ildiko@...<mailto:ildiko@...>
Sent: Thursday, September 6, 2018 9:00 AM
Subject: Re: [akraino] Akraino Charter
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 intentions and expectations when it comes to contributing to and collaborating with Akraino. I assume the TSC is the decision maker on this one?
I believe that setting up the fundamentals right is very important and give clear definitions to people who will join later before we deep dive into implementation details. In that sense I have the same question/request about defining what a blueprint is which is still under discussion as far as I understand, so I will follow/participate in the community calls and discussions to figure that part out.
> On 2018. Sep 6., at 10:36, Margaret Chiosi <margaret.chiosi1@...<mailto:margaret.chiosi1@...>> wrote:
> 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
> +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@...> [mailto:main@...] On Behalf Of fzdarsky@...<mailto:fzdarsky@...>
> Sent: Thursday, September 06, 2018 9:33 AM
> To: main@...<mailto: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...
> On Wed, Sep 5, 2018 at 10:15 PM <ildiko@...<mailto:ildiko@...>> wrote:
> 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?
> > On 2018. Sep 4., at 11:49, Srini <srinivasa.r.addepalli@...<mailto: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@...<mailto:fzdarsky@...> | irc: fzdarsky@freenode | m: +49 175 82 11 64 4
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Frank Zdarsky | NFV&SDN Technology Strategy, Office of the CTO | Red Hat
| irc: fzdarsky@freenode | m: +49 175 82 11 64 4