|
Re: Use cases and Blueprints
Andrew Wilkinson
I wouldn’t see a Test definition (3) as a ‘blueprint’.
Nor would I see specific functional components (2) developed by the Akraino community as ‘blueprints’ either.
I think using the term blueprint for everything tends to make the term too broad. The term blueprint in common parlance is taken to mean the definition of how to build something (e.g. a building – a house or a shed etc). I could of course
be expanded to encompass more (like a test blueprint) but would suggest we keep Akraino blueprints to be more specific and not include functionality or test schedules.
Rather I propose a blueprint be used to classify a set of options that cab result in distinct POD deployments. The term ‘Network Clod blueprint’ would be used as such.
Andrew
toggle quoted message
Show quoted text
From: main@... <main@...>
On Behalf Of Margaret Chiosi
Sent: Thursday, September 13, 2018 4:22 PM
To: main@...
Subject: Re: [Akraino Main] Use cases and Blueprints
I thought in email folks were ok with the following types of blueprint:
1. Architecture
2. components (Physical/virtual) supporting a specific 'use case'
3. Test
|
|
|
Re: Akraino Mail Lists Update - ACTION REQUIRED
On Thu, Sep 13, 2018 at 5:03 PM Jacqueline Serafin <jserafin@...> wrote:
Akraino Community,
In order to facilitate future discussions in clearly delineated forums utilizing open source project best practices we have made changes to the mail lists available for this community. Please review below the lists available and ensure you subscribe to the lists you are interested in by adding yourself to the applicable subgroups.
Subgroups Available:
[new] tsc@...
To be used for top-level technical/governance discussions, TSC agendas/minutes, etc. Open to everyone, not only to TSC members.
[new] technical-discuss@...
To be used for general technical discussion and questions.
The main@... list will remain available but we recommend using this list extremely sparingly, for top-level milestone or critical announcements as the messages will hit all subscribers of all subgroups.
Would it make sense to rename this to "announce@..." then?
As the Akraino project grows and scales we can certainly add additional lists but we’d like to first establish a proper foundation and thoughtfully build from there.
If you have any questions, please reach out.
Thank you,
Jacqueline
Jacqueline Serafin
Program Manager
The Linux Foundation
+1 (415) 676-1127 (m)
jserafin@...
-- Frank Zdarsky | NFV&SDN Technology Strategy, Office of the CTO | Red Hat e: fzdarsky@... | irc: fzdarsky@freenode | m: +49 175 82 11 64 4
|
|
|
Re: Use cases and Blueprints
Margaret Chiosi <margaret.chiosi1@...>
I thought in email folks were ok with the following types of blueprint:
1. Architecture
2. components (Physical/virtual) supporting a specific 'use case'
3. Test
|
|
|
Akraino Mail Lists Update - ACTION REQUIRED
Jacqueline Z Cardoso
Akraino Community,
In order to facilitate future discussions in clearly delineated forums utilizing open source project best practices we have made changes to the mail lists available for this community. Please review below the lists available and ensure you subscribe to the lists you are interested in by adding yourself to the applicable subgroups.
Subgroups Available: To be used for top-level technical/governance discussions, TSC agendas/minutes, etc. Open to everyone, not only to TSC members.
The main@... list will remain available but we recommend using this list extremely sparingly, for top-level milestone or critical announcements as the messages will hit all subscribers of all subgroups.
As the Akraino project grows and scales we can certainly add additional lists but we’d like to first establish a proper foundation and thoughtfully build from there.
If you have any questions, please reach out.
Thank you,
Jacqueline Serafin Program Manager
The Linux Foundation
+1 (415) 676-1127 (m)
|
|
|
Locked
Topics for Akraino community call on September 13th?
Tapio Tallgren <tapio.tallgren@...>
Hi all,
We have scheduled the second Akraino community call for Thursday, September 13th. Since a lot of the people who have contributed to the blueprint discussion on the mailing list have conflicting meetings, I would like to hear suggestions for topics.
-Tapio
|
|
|
Hi Frank,
On this:
“
-
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?
Could you maybe elaborate why you feel it matters whether building images is part of the project or not?
“
I see some projects applying patches (patches that are created in upstream) to their current release instead of taking latest release. This requires capability
of building binaries & packages.
So selectively backporting patches from upstream's master into upstream's stable branch. That's something we might want to do in the upstream branch, too, but I can see the need for exceptions to that. Hope the project can agree on a policy around such selective backporting (vs. carrying out-of-tree patches).
Even otherwise, there are some upstream projects don’t create binary images or images in a way that is required.
For example, Openstack-kolla and Openstack-helm projects can be considered as sister projects to Airship as Kolla project creates container images for each openstack
service and pushes them to dockerhub. Openstak-helm project is the home for helm charts which help in deploying them. I guess Airship installer requires them in containers and helm charts.
Some projects such as libvirtd, ovs, ovs-dpdk, collectd, kubelet, OVN north/south controllers and many more, that are required to be part of the Edge stack, also
need to be containerized and have helm charts. Where do we do them? As Akraino or as a sister project?
My thinking is that to make Akraino complete integration project, it would need to have capabilities to build the images.
Agree there may be a need to build images. Should probably be left to the respective Blueprint projects to decide how to build them, as each project may have tooling that's more "native" to them.
Thoughts?
What about
From: main@... [mailto:main@...]
On Behalf Of fzdarsky@...
Sent: Friday, September 7, 2018 4:20 AM
To: main@...
Subject: Re: [akraino] Akraino Charter
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 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.
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 wouldn't extrapolate from the seed code
to the project's mission/focus that the community needs to agree on.
Then, notice the code is integration code. It pulls in pieces from Airship and other upstreams (which themselves are development projects).
OPNFV is complete integration (seems like
J) 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.
Ok, if you're not talking about patches for backporting but to fix/add functionality this would be forking and I hope we'll establish a clear upstream-first policy to prevent forking. Apart from that it would not be good citizenship to
not upstream / not give upstream the chance to address gaps first, we'd accumulate technical debt that we don't want. I often hear the argument that these patches are "temporary" to enable us to move fast and that there's the intention to eventually upstream...
which from experience hardly ever happens later.
It's a different, of course, if we're talking about plugins like in your Barometer example.
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?
Could you maybe elaborate why you feel it matters whether building images is part of the project or not?
In my view, we should eventually build images to make internal testing and test-driving by users easier. But I'd like to avoid the trap of putting too much emphasis on the images; how they are built, how to harden them, how to tune/optimize
them, etc. Just mentioning this, as it's a topic that typically comes up sooner or later (like recently in ONAP). And it's important to understand that users will likely throw away our images and rebuild & re-test anyway.
-
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.
I'd expect that we'll identify gaps as a result of the integration. If it's a gap in an upstream project, we should absolutely strive to address those gaps there and never carry patches against an upstream project. If it's a functional
gap not addressed by our current upstreams, we should try to find projects that do something similar and see whether we can extend those. Developing ourselves should be last resort and then as an independent (sub-)project that will need to prove its value
to the larger community over time. Plus it should be possible to swap it out for other solutions if they develop elsewhere.
-
How does Akraino intend to make the deployment production quality if it does not maintain/create patches for upstream projects?
Whatever code we produce ourselves should of course strive towards production quality. But it's not our task to create patches to fix upstream projects or even do backports to an upstream's stable branch! That's the job of the upstream
projects themselves.
And because everyone, both upstreams and us, has finite engineering resources, they have to trade off how much time they spend on backports to older, stable branches vs how much time they invest into new features. Plus how many HW/SW configurations
they are able to fully test.
Now consider an edge stack that consists of dozens of components. It's already difficult to find combinations of versions of components that play well together, let alone the complexity of doing backports across all of them.
Next, consider how users would consume Akraino: Would they just download our/upstream images and run them in production? Of course not! They'd have to get commercial support from vendors (unless they have many engineers to burn to go DIY),
but vendors will in most cases not support the exact combination as integrated/tested in Akraino, so the effort we put in there has a relatively low ROI...
TBH, this all makes the goal of "production quality" for the whole Akraino stack rather aspirational than realistic...
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.
Thanks
Srini
-----Original Message-----
From: main@... [mailto:main@...] On Behalf Of
ildiko@...
Sent: Thursday, September 6, 2018 9:00 AM
To: main@...
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.
Thanks,
Ildikó
> On 2018. Sep 6., at 10:36, Margaret Chiosi <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
>
Sophie.johnson1@...
> +1 (908) 541-3590
>
> Futurewei Technologies, Inc.
> Fixed Network Solution CC
> 400 Crossing Blvd
> Bridgewater, NJ 08807
> (cell) +1-732-216-5507
>
> <image001.png>
>
> 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
>
--
Frank Zdarsky | NFV&SDN Technology Strategy, Office of the CTO | Red Hat
e: fzdarsky@... | irc: fzdarsky@freenode | m: +49 175 82 11 64 4
-- Frank Zdarsky | NFV&SDN Technology Strategy, Office of the CTO | Red Hat e: fzdarsky@... | irc: fzdarsky@freenode | m: +49 175 82 11 64 4
|
|
|
Hi Frank,
On this:
“
-
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?
Could you maybe elaborate why you feel it matters whether building images is part of the project or not?
“
I see some projects applying patches (patches that are created in upstream) to their current release instead of taking latest release. This requires capability
of building binaries & packages.
Even otherwise, there are some upstream projects don’t create binary images or images in a way that is required.
For example, Openstack-kolla and Openstack-helm projects can be considered as sister projects to Airship as Kolla project creates container images for each openstack
service and pushes them to dockerhub. Openstak-helm project is the home for helm charts which help in deploying them. I guess Airship installer requires them in containers and helm charts.
Some projects such as libvirtd, ovs, ovs-dpdk, collectd, kubelet, OVN north/south controllers and many more, that are required to be part of the Edge stack, also
need to be containerized and have helm charts. Where do we do them? As Akraino or as a sister project?
My thinking is that to make Akraino complete integration project, it would need to have capabilities to build the images.
Thoughts?
What about
toggle quoted message
Show quoted text
From: main@... [mailto:main@...]
On Behalf Of fzdarsky@...
Sent: Friday, September 7, 2018 4:20 AM
To: main@...
Subject: Re: [akraino] Akraino Charter
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 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.
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 wouldn't extrapolate from the seed code
to the project's mission/focus that the community needs to agree on.
Then, notice the code is integration code. It pulls in pieces from Airship and other upstreams (which themselves are development projects).
OPNFV is complete integration (seems like
J) 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.
Ok, if you're not talking about patches for backporting but to fix/add functionality this would be forking and I hope we'll establish a clear upstream-first policy to prevent forking. Apart from that it would not be good citizenship to
not upstream / not give upstream the chance to address gaps first, we'd accumulate technical debt that we don't want. I often hear the argument that these patches are "temporary" to enable us to move fast and that there's the intention to eventually upstream...
which from experience hardly ever happens later.
It's a different, of course, if we're talking about plugins like in your Barometer example.
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?
Could you maybe elaborate why you feel it matters whether building images is part of the project or not?
In my view, we should eventually build images to make internal testing and test-driving by users easier. But I'd like to avoid the trap of putting too much emphasis on the images; how they are built, how to harden them, how to tune/optimize
them, etc. Just mentioning this, as it's a topic that typically comes up sooner or later (like recently in ONAP). And it's important to understand that users will likely throw away our images and rebuild & re-test anyway.
-
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.
I'd expect that we'll identify gaps as a result of the integration. If it's a gap in an upstream project, we should absolutely strive to address those gaps there and never carry patches against an upstream project. If it's a functional
gap not addressed by our current upstreams, we should try to find projects that do something similar and see whether we can extend those. Developing ourselves should be last resort and then as an independent (sub-)project that will need to prove its value
to the larger community over time. Plus it should be possible to swap it out for other solutions if they develop elsewhere.
-
How does Akraino intend to make the deployment production quality if it does not maintain/create patches for upstream projects?
Whatever code we produce ourselves should of course strive towards production quality. But it's not our task to create patches to fix upstream projects or even do backports to an upstream's stable branch! That's the job of the upstream
projects themselves.
And because everyone, both upstreams and us, has finite engineering resources, they have to trade off how much time they spend on backports to older, stable branches vs how much time they invest into new features. Plus how many HW/SW configurations
they are able to fully test.
Now consider an edge stack that consists of dozens of components. It's already difficult to find combinations of versions of components that play well together, let alone the complexity of doing backports across all of them.
Next, consider how users would consume Akraino: Would they just download our/upstream images and run them in production? Of course not! They'd have to get commercial support from vendors (unless they have many engineers to burn to go DIY),
but vendors will in most cases not support the exact combination as integrated/tested in Akraino, so the effort we put in there has a relatively low ROI...
TBH, this all makes the goal of "production quality" for the whole Akraino stack rather aspirational than realistic...
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.
Thanks
Srini
-----Original Message-----
From: main@... [mailto:main@...] On Behalf Of
ildiko@...
Sent: Thursday, September 6, 2018 9:00 AM
To: main@...
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.
Thanks,
Ildikó
> On 2018. Sep 6., at 10:36, Margaret Chiosi <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
>
Sophie.johnson1@...
> +1 (908) 541-3590
>
> Futurewei Technologies, Inc.
> Fixed Network Solution CC
> 400 Crossing Blvd
> Bridgewater, NJ 08807
> (cell) +1-732-216-5507
>
> <image001.png>
>
> 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
>
--
Frank Zdarsky | NFV&SDN Technology Strategy, Office of the CTO | Red Hat
e: fzdarsky@... | irc: fzdarsky@freenode | m: +49 175 82 11 64 4
|
|
|
Re: Use cases and Blueprints
Margaret Chiosi <margaret.chiosi1@...>
I wasn’t thinking that we would have all these blueprints – so maybe we should update the draft definitions doc on scope of a blueprint. I thought the use case determined the scope. But then a scope of a use
case needs to be defined.
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
toggle quoted message
Show quoted text
From: main@... [mailto:main@...]
On Behalf Of Srini
Sent: Wednesday, September 05, 2018 4:31 PM
To: main@...
Subject: [akraino] Use cases and Blueprints
Hi,
In last Akraino developer conference and break-out session, some clarity started to emerge. But.. several questions remain on the granularity of blueprint. My intention of this email is to start the conversation by asking some high level
questions.
For every use case, there would be set of deployments.
For each deployment, there would be blueprints.
For a given deployment, intention is to have small number of blueprints.
For instance, in case of 5G use case, the deployments can be as follows:
-
Core network cloud deployment
-
Multi-server edge cloud deployment
-
Single server edge cloud deployment
-
Two server edge cloud deployment
-
Headless edge deployment
-
Service Orchestration deployment
-
Regional Cloud controller deployment
-
Regional orchestration deployment
One blueprint in each of above deployments is expected to satisfy 5G use case.
For each deployment, intention is to have as minimum number of blueprints to choose from.
For example, for Multi-Server edge cloud deployment, following blueprints are one possibility:
-
Openstack-x86HW-Ubuntu-NoSDNCtrl-v1
-
K8S-x86HW-Ubuntu-OVN-SRIOVCtrl-v1
There are few questions raised and we are wondering whether there is a need to have modularity in the blue prints.
1.
A given Edge Cloud may not have all uniform servers. Some servers may be legacy, some may be with latest processor ). In future, they may be added with some add-on accelerators or there could be compute nodes with next generation processors.
Also, compute nodes could be from different OEMs. Every time there is new node introduced or enhanced with new add-on accelerators, would it be considered as a new blueprint or is that considered as new version of existing blueprint? New version?
2.
Is OS version expected to be common across all servers? If there is a flexibility, adding a new OS version considered as new blueprint or a new version of existing blueprint? New version?
3.
Any support for new site level orchestrator requires new blueprint. Yes?
4.
Any support for new SDN controller requires new blueprint. Yes?
5.
Any support for new fabric switches requires new blueprint. Yes?
6.
Any addition of additional SW packages to NFVI requires new blueprint. Yes?
7.
If there is a version change in Openstack (say moving from Newton to Pike), SDN Controller or K8S, does it require new blueprint or a new version of the blueprint? New version?
Just few questions for discussions
J
Thanks
Srini
|
|
|
Margaret Chiosi <margaret.chiosi1@...>
Are we converging that we are going to do both integration as well as development projects where necessary?
I agree integration creates tools to do this better which is one form of development and we can build upon OPNFV. But I want to make sure we agree that we will create development projects IF there
is a gap in the open ecosystem to fulfil a function we need.
I think – so we make sure we fulfill the target of ‘edge’ – we define the requirements of what makes an edge. This will force us to just not be another core cloud and truly an edge.
The constraints of an edge based on a RAN deployment is I think radical from a metro edge where there is much more power, cooling, space and even manpower.
Which one are we focusing on? – sorry if I repeated anything that was discussed in MT.
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
toggle quoted message
Show quoted text
From: main@... [mailto:main@...]
On Behalf Of Glenn Seiler
Sent: Friday, September 07, 2018 1:41 PM
To: main@...
Subject: Re: [akraino] Akraino Charter
I think many (most?) vendors who submit a blueprint do intend to support the exact specification of the blueprint they submit.
Either as an in-house solution, or commercially as an ecosystem vendor.
I also concur with Oliver’s note that the goal of Akraino is to have an end to end configuration for a particular edge use case which is complete, tested and production deployable (as stated above, either in-house
or commercially). I think that was always the original intent of the Akraino project as stated back in the original Portland meetup in May.
This does require a fair amount of specificity as to HW and SW components. I believe this is different from a scenario in OPNFV, which is more of a reference platform.
We may want to have different ‘levels’ of specificity; i.e reference platforms that are more modular, and then specific blueprints that define a specific end-to-end deployable configuration that could be based
on a ‘reference’ or scenario. I think that was the meat of the discussion yesterday in the community call about having different levels (but I had to drop early from that call).
-glenn
From:
main@... [mailto:main@...]
On Behalf Of Andrew Wilkinson
Sent: Friday, September 07, 2018 6:58 AM
To: main@...
Subject: Re: [akraino] Akraino Charter
Hi,
Just one point to the comment:
“but vendors will in most cases not support the exact combination as integrated/tested in Akraino,”
I think that’s what we can enable with a given blueprint and precise layer options by means of a (set of) precise specification(s) – then a infra/service vendor will have the option to offer and support a configuration of a Akraino blueprint
(in what ever commercial model [e.g. support etc]) and also for VNF vendors to certify their applications for running on a POD deployed using a given blueprint with an exact blueprint specification(s).
Or an operator can decide to support that specification for a blueprint themselves in house.
Andrew
From: main@... <main@...>
On Behalf Of fzdarsky@...
Sent: Friday, September 07, 2018 4:20 AM
To: main@...
Subject: Re: [akraino] Akraino Charter
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 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.
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 wouldn't extrapolate from the seed code
to the project's mission/focus that the community needs to agree on.
Then, notice the code is integration code. It pulls in pieces from Airship and other upstreams (which themselves are development projects).
OPNFV is complete integration (seems like
J) 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.
Ok, if you're not talking about patches for backporting but to fix/add functionality this would be forking and I hope we'll establish a clear upstream-first policy to prevent forking. Apart from that it would not be good citizenship to
not upstream / not give upstream the chance to address gaps first, we'd accumulate technical debt that we don't want. I often hear the argument that these patches are "temporary" to enable us to move fast and that there's the intention to eventually upstream...
which from experience hardly ever happens later.
It's a different, of course, if we're talking about plugins like in your Barometer example.
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?
Could you maybe elaborate why you feel it matters whether building images is part of the project or not?
In my view, we should eventually build images to make internal testing and test-driving by users easier. But I'd like to avoid the trap of putting too much emphasis on the images; how they are built, how to harden them, how to tune/optimize
them, etc. Just mentioning this, as it's a topic that typically comes up sooner or later (like recently in ONAP). And it's important to understand that users will likely throw away our images and rebuild & re-test anyway.
-
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.
I'd expect that we'll identify gaps as a result of the integration. If it's a gap in an upstream project, we should absolutely strive to address those gaps there and never carry patches against an upstream project. If it's a functional
gap not addressed by our current upstreams, we should try to find projects that do something similar and see whether we can extend those. Developing ourselves should be last resort and then as an independent (sub-)project that will need to prove its value
to the larger community over time. Plus it should be possible to swap it out for other solutions if they develop elsewhere.
-
How does Akraino intend to make the deployment production quality if it does not maintain/create patches for upstream projects?
Whatever code we produce ourselves should of course strive towards production quality. But it's not our task to create patches to fix upstream projects or even do backports to an upstream's stable branch! That's the job of the upstream
projects themselves.
And because everyone, both upstreams and us, has finite engineering resources, they have to trade off how much time they spend on backports to older, stable branches vs how much time they invest into new features. Plus how many HW/SW configurations
they are able to fully test.
Now consider an edge stack that consists of dozens of components. It's already difficult to find combinations of versions of components that play well together, let alone the complexity of doing backports across all of them.
Next, consider how users would consume Akraino: Would they just download our/upstream images and run them in production? Of course not! They'd have to get commercial support from vendors (unless they have many engineers to burn to go DIY),
but vendors will in most cases not support the exact combination as integrated/tested in Akraino, so the effort we put in there has a relatively low ROI...
TBH, this all makes the goal of "production quality" for the whole Akraino stack rather aspirational than realistic...
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.
Thanks
Srini
-----Original Message-----
From: main@... [mailto:main@...] On Behalf Of
ildiko@...
Sent: Thursday, September 6, 2018 9:00 AM
To: main@...
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.
Thanks,
Ildikó
> On 2018. Sep 6., at 10:36, Margaret Chiosi <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
>
Sophie.johnson1@...
> +1 (908) 541-3590
>
> Futurewei Technologies, Inc.
> Fixed Network Solution CC
> 400 Crossing Blvd
> Bridgewater, NJ 08807
> (cell) +1-732-216-5507
>
> <image001.png>
>
> 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
>
--
Frank Zdarsky | NFV&SDN Technology Strategy, Office of the CTO | Red Hat
e: fzdarsky@... | irc: fzdarsky@freenode | m: +49 175 82 11 64 4
|
|
|
Margaret Chiosi <margaret.chiosi1@...>
Since I missed the meeting – my comments – I turned on tracking of changes.
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
toggle quoted message
Show quoted text
From: main@... [mailto:main@...]
On Behalf Of na387s@...
Sent: Friday, September 07, 2018 4:55 PM
To: main@...
Subject: Re: [akraino] Akraino Charter
Hi,
I was going through the emails and the pdfs from the Akraino summit to fully understand the definitions. I think we are getting closer and I am sure the TSC will come out with the official definitions document, but until then I have attached a document with
the definitions that I understood from the summit. Please keep in mind that I got the definitions from the web and based more the world of software development than network. However, I feel as the network world gets closer to the appdev world the definitions
will also become similar.
In the document, I have also put the definitions of the other actors: PODs and Specifications, but I am not sure if the community wants to keep them or not.
Love to get some feedback or clarity on this.
Regards,
|
|
|
Locked
Re: regional controller installation ldap error
Hi Max:
Looking at the logs, it appears you have connectivity issues to your LDAP server.
Please note your LDAP server IP and that of the Regional Controller should be
the same. Please run the command below:
docker exec akraino-ldap /bin/bash -c "ldapadd -v -h $IP:10389 -c -x -D uid=admin,ou=system -w secret -f /bootstrap/conf/akrainousers.ldif"
and for $IP please assign regional server IP address. Please share logs.
For your reference, I have attached the logs from the successful run using the same region script that you have used.
For your other question, we are working to provide scripts to support non Dell R740 serves, such as HP Gen 10 and will share with the community
when our develop and testing is complete.
Best Regards,
Deepak Kataria
|
|
|
Locked
Re: regional controller installation ldap error
Hi Max:
Looking at the logs, it appears you have connectivity issues to your LDAP server.
Please note your LDAP server IP and that of the Regional Controller should be
the same. Please run the command below:
docker exec akraino-ldap /bin/bash -c "ldapadd -v -h $IP:10389 -c -x -D uid=admin,ou=system -w secret -f /bootstrap/conf/akrainousers.ldif"
and for IP please assign regional server IP address. Please share logs.
For your reference, I have attached the logs from the successful run using the same region script that you have used.
For your other question, we are working to provide scripts to support non Dell R740 serves, such as HP Gen 10 and will share with the community
when our develop and testing is complete.
Best Regards,
Deepak Kataria
From: <main@...> on behalf of "rongjie.xu@..."
<rongjie.xu@...>
Reply-To: "main@..." <main@...>
Date: Friday, September 7, 2018 at 10:22 AM
To: "main@..." <main@...>
Subject: [akraino] regional controller installation ldap error
Hi,
I want to set up one edge cloud using Akraino project. I am working on the first step now (installing the regional controller node). As my regional controller is not Dell R740 so i cannot use Akraino provided tools script to automatically provision and deploy
it. I directly install Ubuntu 16.04 and Docker in this server and use region script (https://nexus.akraino.org/service/local/repositories/snapshots/content/org/akraino/regional_controller/regional_controller/1.0.0-SNAPSHOT/regional_controller-1.0.0-20180809.150544-11.tgz)
to install all other necessary software. I got attached errors during installation. Anyone has some knowledge about this?
And as general question, is that possible to deploy edge cloud for non Dell R740 servers?
Br. Max
_._,_._,_
|
|
|
Hi,
I was going through the emails and the pdfs from the Akraino summit to fully understand the definitions. I think we are getting closer and I am sure the TSC will come out with the official definitions document, but until then I have attached a document with the definitions that I understood from the summit. Please keep in mind that I got the definitions from the web and based more the world of software development than network. However, I feel as the network world gets closer to the appdev world the definitions will also become similar.
In the document, I have also put the definitions of the other actors: PODs and Specifications, but I am not sure if the community wants to keep them or not.
Love to get some feedback or clarity on this.
Regards,
|
|
|
Glenn Seiler
I think many (most?) vendors who submit a blueprint do intend to support the exact specification of the blueprint they submit.
Either as an in-house solution, or commercially as an ecosystem vendor.
I also concur with Oliver’s note that the goal of Akraino is to have an end to end configuration for a particular edge use case which is complete, tested and production deployable (as stated above, either in-house
or commercially). I think that was always the original intent of the Akraino project as stated back in the original Portland meetup in May.
This does require a fair amount of specificity as to HW and SW components. I believe this is different from a scenario in OPNFV, which is more of a reference platform.
We may want to have different ‘levels’ of specificity; i.e reference platforms that are more modular, and then specific blueprints that define a specific end-to-end deployable configuration that could be based
on a ‘reference’ or scenario. I think that was the meat of the discussion yesterday in the community call about having different levels (but I had to drop early from that call).
-glenn
toggle quoted message
Show quoted text
From: main@... [mailto:main@...]
On Behalf Of Andrew Wilkinson
Sent: Friday, September 07, 2018 6:58 AM
To: main@...
Subject: Re: [akraino] Akraino Charter
Hi,
Just one point to the comment:
“but vendors will in most cases not support the exact combination as integrated/tested in Akraino,”
I think that’s what we can enable with a given blueprint and precise layer options by means of a (set of) precise specification(s) – then a infra/service vendor will have the option to offer and support a configuration of a Akraino blueprint
(in what ever commercial model [e.g. support etc]) and also for VNF vendors to certify their applications for running on a POD deployed using a given blueprint with an exact blueprint specification(s).
Or an operator can decide to support that specification for a blueprint themselves in house.
Andrew
From: main@... <main@...>
On Behalf Of fzdarsky@...
Sent: Friday, September 07, 2018 4:20 AM
To: main@...
Subject: Re: [akraino] Akraino Charter
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 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.
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 wouldn't extrapolate from the seed code
to the project's mission/focus that the community needs to agree on.
Then, notice the code is integration code. It pulls in pieces from Airship and other upstreams (which themselves are development projects).
OPNFV is complete integration (seems like
J) 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.
Ok, if you're not talking about patches for backporting but to fix/add functionality this would be forking and I hope we'll establish a clear upstream-first policy to prevent forking. Apart from that it would not be good citizenship to
not upstream / not give upstream the chance to address gaps first, we'd accumulate technical debt that we don't want. I often hear the argument that these patches are "temporary" to enable us to move fast and that there's the intention to eventually upstream...
which from experience hardly ever happens later.
It's a different, of course, if we're talking about plugins like in your Barometer example.
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?
Could you maybe elaborate why you feel it matters whether building images is part of the project or not?
In my view, we should eventually build images to make internal testing and test-driving by users easier. But I'd like to avoid the trap of putting too much emphasis on the images; how they are built, how to harden them, how to tune/optimize
them, etc. Just mentioning this, as it's a topic that typically comes up sooner or later (like recently in ONAP). And it's important to understand that users will likely throw away our images and rebuild & re-test anyway.
-
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.
I'd expect that we'll identify gaps as a result of the integration. If it's a gap in an upstream project, we should absolutely strive to address those gaps there and never carry patches against an upstream project. If it's a functional
gap not addressed by our current upstreams, we should try to find projects that do something similar and see whether we can extend those. Developing ourselves should be last resort and then as an independent (sub-)project that will need to prove its value
to the larger community over time. Plus it should be possible to swap it out for other solutions if they develop elsewhere.
-
How does Akraino intend to make the deployment production quality if it does not maintain/create patches for upstream projects?
Whatever code we produce ourselves should of course strive towards production quality. But it's not our task to create patches to fix upstream projects or even do backports to an upstream's stable branch! That's the job of the upstream
projects themselves.
And because everyone, both upstreams and us, has finite engineering resources, they have to trade off how much time they spend on backports to older, stable branches vs how much time they invest into new features. Plus how many HW/SW configurations
they are able to fully test.
Now consider an edge stack that consists of dozens of components. It's already difficult to find combinations of versions of components that play well together, let alone the complexity of doing backports across all of them.
Next, consider how users would consume Akraino: Would they just download our/upstream images and run them in production? Of course not! They'd have to get commercial support from vendors (unless they have many engineers to burn to go DIY),
but vendors will in most cases not support the exact combination as integrated/tested in Akraino, so the effort we put in there has a relatively low ROI...
TBH, this all makes the goal of "production quality" for the whole Akraino stack rather aspirational than realistic...
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.
Thanks
Srini
-----Original Message-----
From: main@... [mailto:main@...] On Behalf Of
ildiko@...
Sent: Thursday, September 6, 2018 9:00 AM
To: main@...
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.
Thanks,
Ildikó
> On 2018. Sep 6., at 10:36, Margaret Chiosi <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
>
Sophie.johnson1@...
> +1 (908) 541-3590
>
> Futurewei Technologies, Inc.
> Fixed Network Solution CC
> 400 Crossing Blvd
> Bridgewater, NJ 08807
> (cell) +1-732-216-5507
>
> <image001.png>
>
> 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
>
--
Frank Zdarsky | NFV&SDN Technology Strategy, Office of the CTO | Red Hat
e: fzdarsky@... | irc: fzdarsky@freenode | m: +49 175 82 11 64 4
|
|
|
Wenjing Chu <Wenjing.Chu@...>
Well said. +1.
Focus on the goal, the end result, and be pragmatic on how to get there.
Wenjing
From: spatsch
Subject: Re: [akraino] Akraino Charter
Time: 2018-09-07 09:37:35
Catching up on this thread let me make a couple of comments.
As we had discussed during the summit I think the TSC is working hard to formalize the precise definition of terms. That will be very useful to ensure we are always talking about the same thing. Hope that will be available soon.
On the scope discussion let me repeat what I had said before.
The goal of Akraino for me is to have an end to end configuration for a particular edge use case which is complete, tested and production deployable. Now what does that imply:
- All the upstream components need to be integrated in a supportable way. Depending on the component that might mean we can use upstream distributions or maybe we go to the source directly. This is really
difficult to answer abstractly. The one thing I do know is that you can’t just download 5 upstream distributions, throw them on a server and call it a production ready “edge cloud”. Everybody who has done more than a POC before knows it is not that easy. The
devil is generally in the details. So as my preference would be to use distributions rather than components I wouldn’t rule either one out but leave it to the team working the blueprint.
- You will need tools to do above e.g. you need workflows to live cycle the collection of all components even if each component has a life cycle tool of its own; you need tools to do cross component fault correlation
and isolation; …. Now some of those tools themselves might be based on upstream components again difficult to answer abstractly.
- As for APIs. I agree with the prior post that most APIs will be defined somewhere else, however, if we want to support that API in the context of that code stack somebody has to write the code to do so. So
that might be something else ending up in Akraino. Also some APIs might be Akraino specify (e.g. the workflows mentioned in the bullet above).
So I would just stay focused on the goal:
“end configuration for a particular edge use case which is complete, tested and production deployable”
and be pragmatic on how to get there.
Oliver
From:
<main@...> on behalf of Andrew Wilkinson <andrew.wilkinson@...>
Reply-To: "main@..." <main@...>
Date: Friday, September 7, 2018 at 9:58 AM
To: "main@..." <main@...>
Subject: Re: [akraino] Akraino Charter
Hi,
Just one point to the comment:
“but vendors will in most cases not support the exact combination as integrated/tested in Akraino,”
I think that’s what we can enable with a given blueprint and precise layer options by means of a (set of) precise specification(s) – then a infra/service vendor will have the option to offer and support
a configuration of a Akraino blueprint (in what ever commercial model [e.g. support etc]) and also for VNF vendors to certify their applications for running on a POD deployed using a given blueprint with an exact blueprint specification(s).
Or an operator can decide to support that specification for a blueprint themselves in house.
Andrew
toggle quoted message
Show quoted text
From: main@... <main@...>
On Behalf Of fzdarsky@...
Sent: Friday, September 07, 2018 4:20 AM
To: main@...
Subject: Re: [akraino] Akraino Charter
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 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.
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
wouldn't extrapolate from the seed code to the project's mission/focus that the community needs to agree on.
Then, notice the code is integration code. It pulls in pieces from Airship and other upstreams (which themselves are development projects).
OPNFV is complete integration (seems like
J) 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.
Ok, if you're not talking about patches for backporting but to fix/add functionality this would be forking and I hope we'll establish a clear upstream-first policy to prevent forking. Apart from that
it would not be good citizenship to not upstream / not give upstream the chance to address gaps first, we'd accumulate technical debt that we don't want. I often hear the argument that these patches are "temporary" to enable us to move fast and that there's
the intention to eventually upstream... which from experience hardly ever happens later.
It's a different, of course, if we're talking about plugins like in your Barometer example.
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?
Could you maybe elaborate why you feel it matters whether building images is part of the project or not?
In my view, we should eventually build images to make internal testing and test-driving by users easier. But I'd like to avoid the trap of putting too much emphasis on the images; how they are built,
how to harden them, how to tune/optimize them, etc. Just mentioning this, as it's a topic that typically comes up sooner or later (like recently in ONAP). And it's important to understand that users will likely throw away our images and rebuild & re-test anyway.
-
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.
I'd expect that we'll identify gaps as a result of the integration. If it's a gap in an upstream project, we should absolutely strive to address those gaps there and never carry patches against an
upstream project. If it's a functional gap not addressed by our current upstreams, we should try to find projects that do something similar and see whether we can extend those. Developing ourselves should be last resort and then as an independent (sub-)project
that will need to prove its value to the larger community over time. Plus it should be possible to swap it out for other solutions if they develop elsewhere.
-
How does Akraino intend to make the deployment production quality if it does not maintain/create patches for upstream projects?
Whatever code we produce ourselves should of course strive towards production quality. But it's not our task to create patches to fix upstream projects or even do backports to an upstream's stable
branch! That's the job of the upstream projects themselves.
And because everyone, both upstreams and us, has finite engineering resources, they have to trade off how much time they spend on backports to older, stable branches vs how much time they invest into
new features. Plus how many HW/SW configurations they are able to fully test.
Now consider an edge stack that consists of dozens of components. It's already difficult to find combinations of versions of components that play well together, let alone the complexity of doing backports
across all of them.
Next, consider how users would consume Akraino: Would they just download our/upstream images and run them in production? Of course not! They'd have to get commercial support from vendors (unless they
have many engineers to burn to go DIY), but vendors will in most cases not support the exact combination as integrated/tested in Akraino, so the effort we put in there has a relatively low ROI...
TBH, this all makes the goal of "production quality" for the whole Akraino stack rather aspirational than realistic...
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.
Thanks
Srini
-----Original Message-----
From: main@... [mailto:main@...]
On Behalf Of ildiko@...
Sent: Thursday, September 6, 2018 9:00 AM
To: main@...
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.
Thanks,
Ildikó
> On 2018. Sep 6., at 10:36, Margaret Chiosi <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
>
Sophie.johnson1@...
> +1 (908) 541-3590
>
> Futurewei Technologies, Inc.
> Fixed Network Solution CC
> 400 Crossing Blvd
> Bridgewater, NJ 08807
> (cell) +1-732-216-5507
>
> <image001.png>
>
> 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
>
--
Frank Zdarsky | NFV&SDN Technology Strategy, Office of the CTO | Red Hat
e: fzdarsky@... | irc: fzdarsky@freenode | m: +49 175 82 11 64 4
|
|
|
Catching up on this thread let me make a couple of comments.
As we had discussed during the summit I think the TSC is working hard to formalize the precise definition of terms. That will be very useful to ensure we are always talking about the same thing. Hope that will be available soon.
On the scope discussion let me repeat what I had said before.
The goal of Akraino for me is to have an end to end configuration for a particular edge use case which is complete, tested and production deployable. Now what does that imply:
- All the upstream components need to be integrated in a supportable way. Depending on the component that might mean we can use upstream distributions or maybe we go to the source directly.
This is really difficult to answer abstractly. The one thing I do know is that you can’t just download 5 upstream distributions, throw them on a server and call it a production ready “edge cloud”. Everybody who has done more than a POC before knows it is not
that easy. The devil is generally in the details. So as my preference would be to use distributions rather than components I wouldn’t rule either one out but leave it to the team working the blueprint.
- You will need tools to do above e.g. you need workflows to live cycle the collection of all components even if each component has a life cycle tool of its own; you need tools to do
cross component fault correlation and isolation; …. Now some of those tools themselves might be based on upstream components again difficult to answer abstractly.
- As for APIs. I agree with the prior post that most APIs will be defined somewhere else, however, if we want to support that API in the context of that code stack somebody has to write
the code to do so. So that might be something else ending up in Akraino. Also some APIs might be Akraino specify (e.g. the workflows mentioned in the bullet above).
So I would just stay focused on the goal:
“end configuration for a particular edge use case which is complete, tested and production deployable”
and be pragmatic on how to get there.
Oliver
From:
<main@...> on behalf of Andrew Wilkinson <andrew.wilkinson@...>
Reply-To: "main@..." <main@...>
Date: Friday, September 7, 2018 at 9:58 AM
To: "main@..." <main@...>
Subject: Re: [akraino] Akraino Charter
Hi,
Just one point to the comment:
“but vendors will in most cases not support the exact combination as integrated/tested in Akraino,”
I think that’s what we can enable with a given blueprint and precise layer options by means of a (set of) precise specification(s) – then a infra/service vendor will
have the option to offer and support a configuration of a Akraino blueprint (in what ever commercial model [e.g. support etc]) and also for VNF vendors to certify their applications for running on a POD deployed using a given blueprint with an exact blueprint
specification(s).
Or an operator can decide to support that specification for a blueprint themselves in house.
Andrew
toggle quoted message
Show quoted text
From: main@... <main@...>
On Behalf Of fzdarsky@...
Sent: Friday, September 07, 2018 4:20 AM
To: main@...
Subject: Re: [akraino] Akraino Charter
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 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.
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 wouldn't extrapolate from the seed code to the project's mission/focus that the community needs to agree on.
Then, notice the code is integration code. It pulls in pieces from Airship and other upstreams (which themselves are development projects).
OPNFV is complete integration (seems like
J) 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.
Ok, if you're not talking about patches for backporting but to fix/add functionality this would be forking and I hope we'll establish a clear upstream-first policy to
prevent forking. Apart from that it would not be good citizenship to not upstream / not give upstream the chance to address gaps first, we'd accumulate technical debt that we don't want. I often hear the argument that these patches are "temporary" to enable
us to move fast and that there's the intention to eventually upstream... which from experience hardly ever happens later.
It's a different, of course, if we're talking about plugins like in your Barometer example.
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?
Could you maybe elaborate why you feel it matters whether building images is part of the project or not?
In my view, we should eventually build images to make internal testing and test-driving by users easier. But I'd like to avoid the trap of putting too much emphasis on
the images; how they are built, how to harden them, how to tune/optimize them, etc. Just mentioning this, as it's a topic that typically comes up sooner or later (like recently in ONAP). And it's important to understand that users will likely throw away our
images and rebuild & re-test anyway.
-
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.
I'd expect that we'll identify gaps as a result of the integration. If it's a gap in an upstream project, we should absolutely strive to address those gaps there and
never carry patches against an upstream project. If it's a functional gap not addressed by our current upstreams, we should try to find projects that do something similar and see whether we can extend those. Developing ourselves should be last resort and then
as an independent (sub-)project that will need to prove its value to the larger community over time. Plus it should be possible to swap it out for other solutions if they develop elsewhere.
-
How does Akraino intend to make the deployment production quality if it does not maintain/create patches for upstream projects?
Whatever code we produce ourselves should of course strive towards production quality. But it's not our task to create patches to fix upstream projects or even do backports
to an upstream's stable branch! That's the job of the upstream projects themselves.
And because everyone, both upstreams and us, has finite engineering resources, they have to trade off how much time they spend on backports to older, stable branches
vs how much time they invest into new features. Plus how many HW/SW configurations they are able to fully test.
Now consider an edge stack that consists of dozens of components. It's already difficult to find combinations of versions of components that play well together, let alone
the complexity of doing backports across all of them.
Next, consider how users would consume Akraino: Would they just download our/upstream images and run them in production? Of course not! They'd have to get commercial
support from vendors (unless they have many engineers to burn to go DIY), but vendors will in most cases not support the exact combination as integrated/tested in Akraino, so the effort we put in there has a relatively low ROI...
TBH, this all makes the goal of "production quality" for the whole Akraino stack rather aspirational than realistic...
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.
Thanks
Srini
-----Original Message-----
From: main@... [mailto:main@...]
On Behalf Of ildiko@...
Sent: Thursday, September 6, 2018 9:00 AM
To: main@...
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.
Thanks,
Ildikó
> On 2018. Sep 6., at 10:36, Margaret Chiosi <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
>
Sophie.johnson1@...
> +1 (908) 541-3590
>
> Futurewei Technologies, Inc.
> Fixed Network Solution CC
> 400 Crossing Blvd
> Bridgewater, NJ 08807
> (cell) +1-732-216-5507
>
> <image001.png>
>
> 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
>
--
Frank Zdarsky | NFV&SDN Technology Strategy, Office of the CTO | Red Hat
e: fzdarsky@... | irc: fzdarsky@freenode
| m: +49 175 82 11 64 4
|
|
|
Hi Frank and all,
On this:
“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.”
Is your thinking that Akraino does similar to what CNCF does? Or do you think that development projects happen at higher level such as Edge umbrella (as LFN)
and keep Akraino as focused deployment project?
Thanks
Srini
toggle quoted message
Show quoted text
From: main@... [mailto:main@...]
On Behalf Of fzdarsky@...
Sent: Friday, September 7, 2018 2:17 AM
To: main@...
Subject: Re: [akraino] Akraino Charter
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
-Tapio
________________________________________
From: main@... <main@...> on behalf of Tina Tsou <tina.tsou@...>
Sent: Friday, September 7, 2018 6:30:27 AM
To: main@...
Subject: Re: [akraino] Akraino Charter
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@...<mailto:srinivasa.r.addepalli@...>> wrote:
Hi,
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.
Thanks
Srini
-----Original Message-----
From: main@...<mailto:main@...> [mailto:main@...]
On Behalf Of ildiko@...<mailto:ildiko@...>
Sent: Thursday, September 6, 2018 9:00 AM
To: main@...<mailto:main@...>
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.
Thanks,
Ildikó
> 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
> Sophie.johnson1@...<mailto:Sophie.johnson1@...>
> +1 (908) 541-3590
>
> Futurewei Technologies, Inc.
> Fixed Network Solution CC
> 400 Crossing Blvd
> Bridgewater, NJ 08807
> (cell) +1-732-216-5507
>
> <image001.png>
>
> 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...
>
> Thanks,
>
> Frank
>
>
> On Wed, Sep 5, 2018 at 10:15 PM <ildiko@...<mailto: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@...<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
e: fzdarsky@... | irc: fzdarsky@freenode | m: +49 175 82 11 64 4
|
|
|
Locked
regional controller installation ldap error
Hi,
I want to set up one edge cloud using Akraino project. I am working on the first step now (installing the regional controller node). As my regional controller is not Dell R740 so i cannot use Akraino provided tools script to automatically provision and deploy it. I directly install Ubuntu 16.04 and Docker in this server and use region script ( to install all other necessary software. I got attached errors during installation. Anyone has some knowledge about this?
And as general question, is that possible to deploy edge cloud for non Dell R740 servers?
Br. Max
|
|
|
Andrew Wilkinson
Hi,
Just one point to the comment:
“but vendors will in most cases not support the exact combination as integrated/tested in Akraino,”
I think that’s what we can enable with a given blueprint and precise layer options by means of a (set of) precise specification(s) – then a infra/service vendor will have the option to offer and support a configuration of a Akraino blueprint
(in what ever commercial model [e.g. support etc]) and also for VNF vendors to certify their applications for running on a POD deployed using a given blueprint with an exact blueprint specification(s).
Or an operator can decide to support that specification for a blueprint themselves in house.
Andrew
toggle quoted message
Show quoted text
From: main@... <main@...>
On Behalf Of fzdarsky@...
Sent: Friday, September 07, 2018 4:20 AM
To: main@...
Subject: Re: [akraino] Akraino Charter
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 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.
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 wouldn't extrapolate from the seed code
to the project's mission/focus that the community needs to agree on.
Then, notice the code is integration code. It pulls in pieces from Airship and other upstreams (which themselves are development projects).
OPNFV is complete integration (seems like
J) 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.
Ok, if you're not talking about patches for backporting but to fix/add functionality this would be forking and I hope we'll establish a clear upstream-first policy to prevent forking. Apart from that it would not be good citizenship to
not upstream / not give upstream the chance to address gaps first, we'd accumulate technical debt that we don't want. I often hear the argument that these patches are "temporary" to enable us to move fast and that there's the intention to eventually upstream...
which from experience hardly ever happens later.
It's a different, of course, if we're talking about plugins like in your Barometer example.
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?
Could you maybe elaborate why you feel it matters whether building images is part of the project or not?
In my view, we should eventually build images to make internal testing and test-driving by users easier. But I'd like to avoid the trap of putting too much emphasis on the images; how they are built, how to harden them, how to tune/optimize
them, etc. Just mentioning this, as it's a topic that typically comes up sooner or later (like recently in ONAP). And it's important to understand that users will likely throw away our images and rebuild & re-test anyway.
-
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.
I'd expect that we'll identify gaps as a result of the integration. If it's a gap in an upstream project, we should absolutely strive to address those gaps there and never carry patches against an upstream project. If it's a functional
gap not addressed by our current upstreams, we should try to find projects that do something similar and see whether we can extend those. Developing ourselves should be last resort and then as an independent (sub-)project that will need to prove its value
to the larger community over time. Plus it should be possible to swap it out for other solutions if they develop elsewhere.
-
How does Akraino intend to make the deployment production quality if it does not maintain/create patches for upstream projects?
Whatever code we produce ourselves should of course strive towards production quality. But it's not our task to create patches to fix upstream projects or even do backports to an upstream's stable branch! That's the job of the upstream
projects themselves.
And because everyone, both upstreams and us, has finite engineering resources, they have to trade off how much time they spend on backports to older, stable branches vs how much time they invest into new features. Plus how many HW/SW configurations
they are able to fully test.
Now consider an edge stack that consists of dozens of components. It's already difficult to find combinations of versions of components that play well together, let alone the complexity of doing backports across all of them.
Next, consider how users would consume Akraino: Would they just download our/upstream images and run them in production? Of course not! They'd have to get commercial support from vendors (unless they have many engineers to burn to go DIY),
but vendors will in most cases not support the exact combination as integrated/tested in Akraino, so the effort we put in there has a relatively low ROI...
TBH, this all makes the goal of "production quality" for the whole Akraino stack rather aspirational than realistic...
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.
Thanks
Srini
-----Original Message-----
From: main@... [mailto:main@...] On Behalf Of
ildiko@...
Sent: Thursday, September 6, 2018 9:00 AM
To: main@...
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.
Thanks,
Ildikó
> On 2018. Sep 6., at 10:36, Margaret Chiosi <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
>
Sophie.johnson1@...
> +1 (908) 541-3590
>
> Futurewei Technologies, Inc.
> Fixed Network Solution CC
> 400 Crossing Blvd
> Bridgewater, NJ 08807
> (cell) +1-732-216-5507
>
> <image001.png>
>
> 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
>
--
Frank Zdarsky | NFV&SDN Technology Strategy, Office of the CTO | Red Hat
e: fzdarsky@... | irc: fzdarsky@freenode | m: +49 175 82 11 64 4
|
|
|
Georg Kunz <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
toggle quoted message
Show quoted text
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...
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
|
|
|
