Date   

Re: Akraino Charter

fzdarsky@...
 

On Fri, Sep 7, 2018 at 12:02 AM Srini <srinivasa.r.addepalli@...> wrote:

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


locked Re: Suspected SPAM - Re: [akraino] Akraino community call on Thursday September 6 11-12 Eastern Time

Tapio Tallgren <tapio.tallgren@...>
 

Hi all,

Thanks for the lively discussion! Link to my slides is https://docs.google.com/presentation/d/e/2PACX-1vQ2JaQIf4jODwaHtHix8ukKnNk5au3-6F2V6sZEgdh7vFT8LFnZcWhE9KDxY1GXfI2-lNHX6GEyYbsa/pub?start=false&loop=false&delayms=3000

-Tapio

________________________________________
From: main@lists.akraino.org <main@lists.akraino.org> on behalf of Tapio Tallgren <tapio.tallgren@nokia.com>
Sent: Wednesday, September 5, 2018 11:02:09 PM
To: main@lists.akraino.org
Subject: Suspected SPAM - Re: [akraino] Akraino community call on Thursday September 6 11-12 Eastern Time

Yes, the idea is that this would be a weekly call.

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: main@lists.akraino.org <main@lists.akraino.org> on behalf of Margaret Chiosi <margaret.chiosi1@huawei.com>
Sent: Wednesday, September 5, 2018 11:00:41 PM
To: main@lists.akraino.org
Subject: Re: [akraino] Akraino community call on Thursday September 6 11-12 Eastern Time

Is this the weekly call set?

Thank You,
Margaret Chiosi
VP Open Ecosystem Team

Admin: Sophie Johnson
Sophie.johnson1@huawei.com
+1 (908) 541-3590

Futurewei Technologies, Inc.
Fixed Network Solution CC
400 Crossing Blvd
Bridgewater, NJ 08807
(cell) +1-732-216-5507



-----Original Message-----
From: main@lists.akraino.org [mailto:main@lists.akraino.org] On Behalf Of Tapio Tallgren
Sent: Wednesday, September 05, 2018 3:34 PM
To: main@lists.akraino.org
Subject: [akraino] Akraino community call on Thursday September 6 11-12 Eastern Time

Hi all,

Similar to other open source projects, Akraino will have a regular community call where members of the developer community can discuss issues in more depth than what can be done in for example the Technical Steering Committee (TSC) calls. The very first call be on Thursday, September 6th, starting at 11 Eastern Time.

The topics in the community call will vary depending on the ongoing discussions in the mailing lists. For this first event, I can give a summary of the developer event and give an overview on the governance documents that the TSC is working on. A discussion topic is blueprints and horizontal projects -- these may not be the final names.

Link to the event is:

https://wiki.akraino.org/display/AK/Technical+Community

Welcome to join!


Re: Akraino Charter

Tapio Tallgren <tapio.tallgren@...>
 

I agree with Tina, my assumption has been that Akraino does both integration (blueprints) and development ("horizontal projects").

OPNFV seems to have an image problem in that it is seen to be only 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.

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).

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@lists.akraino.org <main@lists.akraino.org> on behalf of Tina Tsou <tina.tsou@arm.com>
Sent: Friday, September 7, 2018 6:30:27 AM
To: main@lists.akraino.org
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@intel.com<mailto:srinivasa.r.addepalli@intel.com>> 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@lists.akraino.org<mailto:main@lists.akraino.org> [mailto:main@lists.akraino.org] On Behalf Of ildiko@openstack.org<mailto:ildiko@openstack.org>
Sent: Thursday, September 6, 2018 9:00 AM
To: main@lists.akraino.org<mailto:main@lists.akraino.org>
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@huawei.com<mailto:margaret.chiosi1@huawei.com>> 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@huawei.com<mailto:Sophie.johnson1@huawei.com>
+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@lists.akraino.org<mailto:main@lists.akraino.org> [mailto:main@lists.akraino.org] On Behalf Of fzdarsky@redhat.com<mailto:fzdarsky@redhat.com>
Sent: Thursday, September 06, 2018 9:33 AM
To: main@lists.akraino.org<mailto:main@lists.akraino.org>
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@openstack.org<mailto:ildiko@openstack.org>> 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@intel.com<mailto:srinivasa.r.addepalli@intel.com>> 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@redhat.com<mailto:fzdarsky@redhat.com> | 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.


Re: Akraino Charter

Tina Tsou
 

Dear Srini et al,

Good questions.

In my mind, Akraino is Integration + Development project.


Thank you,
Tina

On Sep 6, 2018, at 3:02 PM, Srini <srinivasa.r.addepalli@...> wrote:

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.

 

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.

 

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@...] 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

>

 

 

 

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.


Re: Akraino Charter

Srini
 

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.

 

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.

 

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@...] 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

>

 

 

 


Re: Use cases and Blueprints

Andrew Wilkinson
 

Hi All,

 

Please find attached the material discussed today for your reference.

 

Andrew

 

 

 

From: main@... <main@...> On Behalf Of Andrew Wilkinson
Sent: Thursday, September 06, 2018 6:53 AM
To: main@...
Subject: Re: [akraino] Use cases and Blueprints

 

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

 

One way or another though the POD is different and needs to be captured somehow.

 

Let’s discuss in the working group later

 

Andrew

 

From: main@... <main@...> On Behalf Of Reith, Lothar
Sent: Thursday, September 06, 2018 2:06 AM
To: main@...
Subject: Re: [akraino] Use cases and Blueprints

 

Hi,

 

I like to comment on the example “5G use case”, suggesting multiple deployments (thus multiple blueprints) depending on number of servers etc.

 

I must say I don’t love the implied idea of LCM/ 5G capacity management process having to switch between blueprints when adding a server.

 

I rather would like to see one blueprint for the 5G use case for 5G Core Network “Cloud” deployment  where the blueprint specification contains constraints regarding the “Cloud”-type, for example a constraint restricting the “Cloud” to the case where the “Cloud” is a single server edge cloud.

 

So in essence, this contribution is proposing to consider the unification of the example with 8 deployments (and “Blueprints”) into a single Blueprint, in order to avoid “Blueprint fragmentation with partially overlapping fragments” from the outset.

 

Lothar

 

Von: main@... [mailto:main@...] Im Auftrag von Andrew Wilkinson
Gesendet: Donnerstag, 6. September 2018 00:00
An: main@...
Betreff: Re: [akraino] Use cases and Blueprints

 

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

 

From: main@... <main@...> On Behalf Of Srini
Sent: Wednesday, September 05, 2018 1: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.

 

 

>>Yes but they have to be appropriate for the organization deploying them. My small set may be different to your small set.

>>They have to be customizable to be relevant to a wide audience

 

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?

 

 

>>One proposal that I’ve started to sketch in the charter doc is the concept of a Blueprint Specification that accompanies a more generic Blueprint

>>The Specification would precisely and declaratively define the HW and SW in a POD and the LCM approach to a deployment of the POD described by that Blueprint + Blueprint Specification.

>>The Blueprint Specification would need to be layered (e.g., HW, networking, virtualization layers etc etc) and would allow one to do exactly what you described above (Openstack-x86HW-Ubuntu-

 

NoSDNCtrl-v1 OR K8S-x86HW-Ubuntu-OVN-SRIOVCtrl-v1 etc in the same Blueprint)

 

>>Subsequent releases of Akraino for a given Blueprint would add options that could be chosen to form the Blueprint’s Specification

>>The individual functions/plugins/HW in a precise Blueprint’s Specification would be selected from the Blueprint Specification Template.

>>The Blueprint Specification Template would contain all the options supported for a given Blueprint at a given Akraino release.

 

  1. 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?

 

>>We have to support different OS versions and distros in different PODs for sure but should one POD support a mix in the (single) POD?

>>Technically it could but I feel it’ll make the definition and management extremely complex

>>But in forming the definition of a blueprint we should consider it for future as we may then want to structure that definition to support in future multiple options of the same component.

 

  1. Any support for new site level orchestrator requires new blueprint.  Yes?

 

  1. Any support for new SDN controller requires new blueprint. Yes?

 

 

>>I don’t think so if an SDN controller is a plugin option within the Blueprint’s Specification. If not then yes.

>>I could deploy openstack in a Network Cloud Blueprint by selecting different controllers from the set of controller options (e.g. neutron without a controller, ODL or TitaniumFabric controller etc – assuming all were available and tested in a given Akraino release of the ‘Network Cloud’ Blueprint)

 

  1. Any support for new fabric switches requires new blueprint. Yes?

 

>>I wouldn’t assume so by default

>>Let’s say for example a blueprint + spec require L2 only between deployed HW and used only MAC learning – changing the fabric switches out doesn’t have to change the deployment of the POD if the two switches have the same capability.

>>The key question is is the switch fabric managed by the LCM and deployment tools of the Blueprint? If so then you’d need to at least have an option for the different switches in the Blueprint Specification (or have a different Blueprint)

 

  1. Any addition of additional SW packages to NFVI requires new blueprint. Yes?

 

>>Again don’t think so – this will explode the number of Blueprints

>>A different selection of functionalities from those support in a given the Blueprint Specification Template for a given Akraino release would allow one to deploy different SW within the same Blueprint

>>BUT the same question arises about mixing in the same POD deployed by a given Blueprint + Specification as you raised for the OS mixing

>>Think we need more discussion here

 

  1. 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?

>>I’d see this as a change to the blueprint specification not the blueprint itself – i.e. one selects a different OS SW “plugin’ from the template

 

Just few questions for discussions J

 

Thanks

Srini

 

 


Re: Akraino Charter

ildiko@...
 

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@huawei.com> 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@huawei.com
+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@lists.akraino.org [mailto:main@lists.akraino.org] On Behalf Of fzdarsky@redhat.com
Sent: Thursday, September 06, 2018 9:33 AM
To: main@lists.akraino.org
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@openstack.org> 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@intel.com> 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@redhat.com | irc: fzdarsky@freenode | m: +49 175 82 11 64 4


Re: Akraino Charter

Margaret Chiosi <margaret.chiosi1@...>
 

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

The reason why OPNFV turned into integration is because we could NOT attract enough developers.

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

Or maybe just build on OPNFV labs.

 

Thank You,

Margaret Chiosi

VP Open Ecosystem Team

 

Admin: Sophie Johnson

Sophie.johnson1@...

+1 (908) 541-3590

 

Futurewei Technologies, Inc.

Fixed Network Solution CC

400 Crossing Blvd

Bridgewater, NJ 08807

(cell) +1-732-216-5507

 

 

From: main@... [mailto:main@...] On Behalf Of fzdarsky@...
Sent: Thursday, September 06, 2018 9:33 AM
To: main@...
Subject: Re: [akraino] Akraino Charter

 

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

 

I hope we can agree that Akraino is an *integration project*, whose mission it is (paraphrasing from Charter) to make it easier for our users to design/customize, build, and operate edge stacks for their given use case.

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

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

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

 

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

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

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

 

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

 

Thanks,

 

Frank

 

 

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

Hi,

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

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

Thanks,
Ildikó


> On 2018. Sep 4., at 11:49, Srini <srinivasa.r.addepalli@...> wrote:
>
> Hi Akraino TSC,
>
> In the last developer conference, TSC has taken an AI to come out with the Akraino charter definition.
> Much of the discussion on last developer conference is mostly about blueprints, except for one break-out session.
>
> In regional orchestration, Edge API and AI breakout session, we talked about the need for them and the consensus is that Akraino project is the right place to develop them.  In one of the Kandan’s presentation, it was clear that Akraino is not only for developing blueprints for various use cases, but is also a home for Edge related open source projects for the functionality where there is a gap in the open source community. Please consider making the Akraino charter clear on the aspect of development projects to avoid any confusion.
>
> Thanks
> Srini
>
>
>
>




 

--

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


Re: Use cases and Blueprints

Andrew Wilkinson
 

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

 

One way or another though the POD is different and needs to be captured somehow.

 

Let’s discuss in the working group later

 

Andrew

 

From: main@... <main@...> On Behalf Of Reith, Lothar
Sent: Thursday, September 06, 2018 2:06 AM
To: main@...
Subject: Re: [akraino] Use cases and Blueprints

 

Hi,

 

I like to comment on the example “5G use case”, suggesting multiple deployments (thus multiple blueprints) depending on number of servers etc.

 

I must say I don’t love the implied idea of LCM/ 5G capacity management process having to switch between blueprints when adding a server.

 

I rather would like to see one blueprint for the 5G use case for 5G Core Network “Cloud” deployment  where the blueprint specification contains constraints regarding the “Cloud”-type, for example a constraint restricting the “Cloud” to the case where the “Cloud” is a single server edge cloud.

 

So in essence, this contribution is proposing to consider the unification of the example with 8 deployments (and “Blueprints”) into a single Blueprint, in order to avoid “Blueprint fragmentation with partially overlapping fragments” from the outset.

 

Lothar

 

Von: main@... [mailto:main@...] Im Auftrag von Andrew Wilkinson
Gesendet: Donnerstag, 6. September 2018 00:00
An: main@...
Betreff: Re: [akraino] Use cases and Blueprints

 

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

 

From: main@... <main@...> On Behalf Of Srini
Sent: Wednesday, September 05, 2018 1: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.

 

 

>>Yes but they have to be appropriate for the organization deploying them. My small set may be different to your small set.

>>They have to be customizable to be relevant to a wide audience

 

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?

 

 

>>One proposal that I’ve started to sketch in the charter doc is the concept of a Blueprint Specification that accompanies a more generic Blueprint

>>The Specification would precisely and declaratively define the HW and SW in a POD and the LCM approach to a deployment of the POD described by that Blueprint + Blueprint Specification.

>>The Blueprint Specification would need to be layered (e.g., HW, networking, virtualization layers etc etc) and would allow one to do exactly what you described above (Openstack-x86HW-Ubuntu-

 

NoSDNCtrl-v1 OR K8S-x86HW-Ubuntu-OVN-SRIOVCtrl-v1 etc in the same Blueprint)

 

>>Subsequent releases of Akraino for a given Blueprint would add options that could be chosen to form the Blueprint’s Specification

>>The individual functions/plugins/HW in a precise Blueprint’s Specification would be selected from the Blueprint Specification Template.

>>The Blueprint Specification Template would contain all the options supported for a given Blueprint at a given Akraino release.

 

  1. 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?

 

>>We have to support different OS versions and distros in different PODs for sure but should one POD support a mix in the (single) POD?

>>Technically it could but I feel it’ll make the definition and management extremely complex

>>But in forming the definition of a blueprint we should consider it for future as we may then want to structure that definition to support in future multiple options of the same component.

 

  1. Any support for new site level orchestrator requires new blueprint.  Yes?

 

  1. Any support for new SDN controller requires new blueprint. Yes?

 

 

>>I don’t think so if an SDN controller is a plugin option within the Blueprint’s Specification. If not then yes.

>>I could deploy openstack in a Network Cloud Blueprint by selecting different controllers from the set of controller options (e.g. neutron without a controller, ODL or TitaniumFabric controller etc – assuming all were available and tested in a given Akraino release of the ‘Network Cloud’ Blueprint)

 

  1. Any support for new fabric switches requires new blueprint. Yes?

 

>>I wouldn’t assume so by default

>>Let’s say for example a blueprint + spec require L2 only between deployed HW and used only MAC learning – changing the fabric switches out doesn’t have to change the deployment of the POD if the two switches have the same capability.

>>The key question is is the switch fabric managed by the LCM and deployment tools of the Blueprint? If so then you’d need to at least have an option for the different switches in the Blueprint Specification (or have a different Blueprint)

 

  1. Any addition of additional SW packages to NFVI requires new blueprint. Yes?

 

>>Again don’t think so – this will explode the number of Blueprints

>>A different selection of functionalities from those support in a given the Blueprint Specification Template for a given Akraino release would allow one to deploy different SW within the same Blueprint

>>BUT the same question arises about mixing in the same POD deployed by a given Blueprint + Specification as you raised for the OS mixing

>>Think we need more discussion here

 

  1. 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?

>>I’d see this as a change to the blueprint specification not the blueprint itself – i.e. one selects a different OS SW “plugin’ from the template

 

Just few questions for discussions J

 

Thanks

Srini

 

 


Re: Akraino Charter

Srini
 

Thank you for discussion on this.

 

Terminology suggested by Wenjing on categorization (features/functional and integration) seems good to me too.

 

Thanks

Srini

 

 

From: main@... [mailto:main@...] On Behalf Of Margaret Chiosi
Sent: Thursday, September 6, 2018 5:11 AM
To: main@...
Subject: Re: [akraino] Akraino Charter

 

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

I don’t think we need any more granular splits than these.

 

Thank You,

Margaret Chiosi

VP Open Ecosystem Team

 

Admin: Sophie Johnson

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 Andrew Wilkinson
Sent: Wednesday, September 05, 2018 6:42 PM
To: main@...
Subject: Re: [akraino] Akraino Charter

 

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

 

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

 

Andrew

 

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

 

Glenn,

I think you were referring to:
- feature project
- integration project (close to what Akraino calls blueprint)

as used in opnfv.

That was my proposal, if we could convince everyone the use of the terms.

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

Wenjing

From: Glenn Seiler

To: main<main@...>

Subject: Re: [akraino] Akraino Charter

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

 

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

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

 

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

 

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

-glenn

 

 

 

 

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

 

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

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

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

Wenjing

From: Thomas Nadeau

To: main<main@...>

Subject: Re: [akraino] Akraino Charter

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

 

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

 

--Tom

 

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

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

 

Wenjing

 

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

 

 

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

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

 

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

 

-        Functional projects develop functionalities to fill identified gaps.

 

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

 

--Tom

 

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

 

Wenjing

 

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

 

Hi Akraino TSC,

 

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

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

 

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

 

Thanks

Srini

 

 

 


Re: Use cases and Blueprints

Reith, Lothar
 

Hi,

 

I like to comment on the example “5G use case”, suggesting multiple deployments (thus multiple blueprints) depending on number of servers etc.

 

I must say I don’t love the implied idea of LCM/ 5G capacity management process having to switch between blueprints when adding a server.

 

I rather would like to see one blueprint for the 5G use case for 5G Core Network “Cloud” deployment  where the blueprint specification contains constraints regarding the “Cloud”-type, for example a constraint restricting the “Cloud” to the case where the “Cloud” is a single server edge cloud.

 

So in essence, this contribution is proposing to consider the unification of the example with 8 deployments (and “Blueprints”) into a single Blueprint, in order to avoid “Blueprint fragmentation with partially overlapping fragments” from the outset.

 

Lothar

 

Von: main@... [mailto:main@...] Im Auftrag von Andrew Wilkinson
Gesendet: Donnerstag, 6. September 2018 00:00
An: main@...
Betreff: Re: [akraino] Use cases and Blueprints

 

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

 

From: main@... <main@...> On Behalf Of Srini
Sent: Wednesday, September 05, 2018 1: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.

 

 

>>Yes but they have to be appropriate for the organization deploying them. My small set may be different to your small set.

>>They have to be customizable to be relevant to a wide audience

 

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?

 

 

>>One proposal that I’ve started to sketch in the charter doc is the concept of a Blueprint Specification that accompanies a more generic Blueprint

>>The Specification would precisely and declaratively define the HW and SW in a POD and the LCM approach to a deployment of the POD described by that Blueprint + Blueprint Specification.

>>The Blueprint Specification would need to be layered (e.g., HW, networking, virtualization layers etc etc) and would allow one to do exactly what you described above (Openstack-x86HW-Ubuntu-

 

NoSDNCtrl-v1 OR K8S-x86HW-Ubuntu-OVN-SRIOVCtrl-v1 etc in the same Blueprint)

 

>>Subsequent releases of Akraino for a given Blueprint would add options that could be chosen to form the Blueprint’s Specification

>>The individual functions/plugins/HW in a precise Blueprint’s Specification would be selected from the Blueprint Specification Template.

>>The Blueprint Specification Template would contain all the options supported for a given Blueprint at a given Akraino release.

 

  1. 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?

 

>>We have to support different OS versions and distros in different PODs for sure but should one POD support a mix in the (single) POD?

>>Technically it could but I feel it’ll make the definition and management extremely complex

>>But in forming the definition of a blueprint we should consider it for future as we may then want to structure that definition to support in future multiple options of the same component.

 

  1. Any support for new site level orchestrator requires new blueprint.  Yes?

 

  1. Any support for new SDN controller requires new blueprint. Yes?

 

 

>>I don’t think so if an SDN controller is a plugin option within the Blueprint’s Specification. If not then yes.

>>I could deploy openstack in a Network Cloud Blueprint by selecting different controllers from the set of controller options (e.g. neutron without a controller, ODL or TitaniumFabric controller etc – assuming all were available and tested in a given Akraino release of the ‘Network Cloud’ Blueprint)

 

  1. Any support for new fabric switches requires new blueprint. Yes?

 

>>I wouldn’t assume so by default

>>Let’s say for example a blueprint + spec require L2 only between deployed HW and used only MAC learning – changing the fabric switches out doesn’t have to change the deployment of the POD if the two switches have the same capability.

>>The key question is is the switch fabric managed by the LCM and deployment tools of the Blueprint? If so then you’d need to at least have an option for the different switches in the Blueprint Specification (or have a different Blueprint)

 

  1. Any addition of additional SW packages to NFVI requires new blueprint. Yes?

 

>>Again don’t think so – this will explode the number of Blueprints

>>A different selection of functionalities from those support in a given the Blueprint Specification Template for a given Akraino release would allow one to deploy different SW within the same Blueprint

>>BUT the same question arises about mixing in the same POD deployed by a given Blueprint + Specification as you raised for the OS mixing

>>Think we need more discussion here

 

  1. 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?

>>I’d see this as a change to the blueprint specification not the blueprint itself – i.e. one selects a different OS SW “plugin’ from the template

 

Just few questions for discussions J

 

Thanks

Srini

 

 


Re: Akraino Charter

fzdarsky@...
 

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


Re: Akraino Charter

Margaret Chiosi <margaret.chiosi1@...>
 

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

I don’t think we need any more granular splits than these.

 

Thank You,

Margaret Chiosi

VP Open Ecosystem Team

 

Admin: Sophie Johnson

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 Andrew Wilkinson
Sent: Wednesday, September 05, 2018 6:42 PM
To: main@...
Subject: Re: [akraino] Akraino Charter

 

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

 

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

 

Andrew

 

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

 

Glenn,

I think you were referring to:
- feature project
- integration project (close to what Akraino calls blueprint)

as used in opnfv.

That was my proposal, if we could convince everyone the use of the terms.

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

Wenjing

From: Glenn Seiler

To: main<main@...>

Subject: Re: [akraino] Akraino Charter

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

 

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

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

 

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

 

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

-glenn

 

 

 

 

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

 

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

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

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

Wenjing

From: Thomas Nadeau

To: main<main@...>

Subject: Re: [akraino] Akraino Charter

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

 

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

 

--Tom

 

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

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

 

Wenjing

 

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

 

 

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

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

 

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

 

-        Functional projects develop functionalities to fill identified gaps.

 

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

 

--Tom

 

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

 

Wenjing

 

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

 

Hi Akraino TSC,

 

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

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

 

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

 

Thanks

Srini

 

 

 


Re: Use cases and Blueprints

bob monkman
 

Thanks Andrew, Srini,

 

              We will certainly need something like the concept of a Blueprint Specification to address variants of a common general blueprint where a certain OS, CPU Arch, SDN Controller, Vswitch is utilized.

Regards,

Bob

 

Robert (Bob) Monkman

Director, Networking Software Strategy & Ecosystem Programs

Arm

150 Rose Orchard Way

San Jose, Ca 95134

M: +1.510.676.5490

Skype: robert.monkman

 

From: main@... <main@...> On Behalf Of Andrew Wilkinson
Sent: Wednesday, September 5, 2018 3:00 PM
To: main@...
Subject: Re: [akraino] Use cases and Blueprints

 

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

 

From: main@... <main@...> On Behalf Of Srini
Sent: Wednesday, September 05, 2018 1: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.

 

 

>>Yes but they have to be appropriate for the organization deploying them. My small set may be different to your small set.

>>They have to be customizable to be relevant to a wide audience

 

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?

 

 

>>One proposal that I’ve started to sketch in the charter doc is the concept of a Blueprint Specification that accompanies a more generic Blueprint

>>The Specification would precisely and declaratively define the HW and SW in a POD and the LCM approach to a deployment of the POD described by that Blueprint + Blueprint Specification.

>>The Blueprint Specification would need to be layered (e.g., HW, networking, virtualization layers etc etc) and would allow one to do exactly what you described above (Openstack-x86HW-Ubuntu-

 

NoSDNCtrl-v1 OR K8S-x86HW-Ubuntu-OVN-SRIOVCtrl-v1 etc in the same Blueprint)

 

>>Subsequent releases of Akraino for a given Blueprint would add options that could be chosen to form the Blueprint’s Specification

>>The individual functions/plugins/HW in a precise Blueprint’s Specification would be selected from the Blueprint Specification Template.

>>The Blueprint Specification Template would contain all the options supported for a given Blueprint at a given Akraino release.

 

  1. 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?

 

>>We have to support different OS versions and distros in different PODs for sure but should one POD support a mix in the (single) POD?

>>Technically it could but I feel it’ll make the definition and management extremely complex

>>But in forming the definition of a blueprint we should consider it for future as we may then want to structure that definition to support in future multiple options of the same component.

 

  1. Any support for new site level orchestrator requires new blueprint.  Yes?

 

  1. Any support for new SDN controller requires new blueprint. Yes?

 

 

>>I don’t think so if an SDN controller is a plugin option within the Blueprint’s Specification. If not then yes.

>>I could deploy openstack in a Network Cloud Blueprint by selecting different controllers from the set of controller options (e.g. neutron without a controller, ODL or TitaniumFabric controller etc – assuming all were available and tested in a given Akraino release of the ‘Network Cloud’ Blueprint)

 

  1. Any support for new fabric switches requires new blueprint. Yes?

 

>>I wouldn’t assume so by default

>>Let’s say for example a blueprint + spec require L2 only between deployed HW and used only MAC learning – changing the fabric switches out doesn’t have to change the deployment of the POD if the two switches have the same capability.

>>The key question is is the switch fabric managed by the LCM and deployment tools of the Blueprint? If so then you’d need to at least have an option for the different switches in the Blueprint Specification (or have a different Blueprint)

 

  1. Any addition of additional SW packages to NFVI requires new blueprint. Yes?

 

>>Again don’t think so – this will explode the number of Blueprints

>>A different selection of functionalities from those support in a given the Blueprint Specification Template for a given Akraino release would allow one to deploy different SW within the same Blueprint

>>BUT the same question arises about mixing in the same POD deployed by a given Blueprint + Specification as you raised for the OS mixing

>>Think we need more discussion here

 

  1. 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?

>>I’d see this as a change to the blueprint specification not the blueprint itself – i.e. one selects a different OS SW “plugin’ from the template

 

Just few questions for discussions J

 

Thanks

Srini

 

 

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.


Re: Akraino Charter

Glenn Seiler
 

Yes, thank you Wenjing

That is what I was referring to – I think an integration project and a functional project are very  different and the blueprints for each would be substantially different enough that calling them both a ‘blueprint’ dilutes what the original intent of the Akraino blueprint was intended to be.

 

-glenn

 

 

 

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

 

Glenn,

I think you were referring to:
- feature project
- integration project (close to what Akraino calls blueprint)

as used in opnfv.

That was my proposal, if we could convince everyone the use of the terms.

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

Wenjing

From: Glenn Seiler

To: main<main@...>

Subject: Re: [akraino] Akraino Charter

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

 

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

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

 

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

 

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

-glenn

 

 

 

 

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

 

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

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

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

Wenjing

From: Thomas Nadeau

To: main<main@...>

Subject: Re: [akraino] Akraino Charter

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

 

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

 

--Tom

 

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

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

 

Wenjing

 

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

 

 

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

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

 

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

 

-        Functional projects develop functionalities to fill identified gaps.

 

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

 

--Tom

 

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

 

Wenjing

 

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

 

Hi Akraino TSC,

 

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

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

 

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

 

Thanks

Srini

 

 

 


Re: Akraino Charter

Andrew Wilkinson
 

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

 

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

 

Andrew

 

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

 

Glenn,

I think you were referring to:
- feature project
- integration project (close to what Akraino calls blueprint)

as used in opnfv.

That was my proposal, if we could convince everyone the use of the terms.

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

Wenjing

From: Glenn Seiler

To: main<main@...>

Subject: Re: [akraino] Akraino Charter

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

 

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

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

 

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

 

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

-glenn

 

 

 

 

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

 

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

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

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

Wenjing

From: Thomas Nadeau

To: main<main@...>

Subject: Re: [akraino] Akraino Charter

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

 

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

 

--Tom

 

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

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

 

Wenjing

 

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

 

 

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

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

 

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

 

-        Functional projects develop functionalities to fill identified gaps.

 

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

 

--Tom

 

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

 

Wenjing

 

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

 

Hi Akraino TSC,

 

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

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

 

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

 

Thanks

Srini

 

 

 


Re: Akraino Charter

Wenjing Chu <Wenjing.Chu@...>
 

Glenn,

I think you were referring to:
- feature project
- integration project (close to what Akraino calls blueprint)

as used in opnfv.

That was my proposal, if we could convince everyone the use of the terms.

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

Wenjing


From: Glenn Seiler
To: main<main@...>
Subject: Re: [akraino] Akraino Charter
Time: 2018-09-05 14:03:18

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

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

 

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

 

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

-glenn

 

 

 

 

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

 

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

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

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

Wenjing

From: Thomas Nadeau

To: main<main@...>

Subject: Re: [akraino] Akraino Charter

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

 

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

 

--Tom

 

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

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

 

Wenjing

 

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

 

 

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

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

 

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

 

-        Functional projects develop functionalities to fill identified gaps.

 

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

 

--Tom

 

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

 

Wenjing

 

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

 

Hi Akraino TSC,

 

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

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

 

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

 

Thanks

Srini

 

 

 


Re: Use cases and Blueprints

Andrew Wilkinson
 

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

 

From: main@... <main@...> On Behalf Of Srini
Sent: Wednesday, September 05, 2018 1: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.

 

 

>>Yes but they have to be appropriate for the organization deploying them. My small set may be different to your small set.

>>They have to be customizable to be relevant to a wide audience

 

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?

 

 

>>One proposal that I’ve started to sketch in the charter doc is the concept of a Blueprint Specification that accompanies a more generic Blueprint

>>The Specification would precisely and declaratively define the HW and SW in a POD and the LCM approach to a deployment of the POD described by that Blueprint + Blueprint Specification.

>>The Blueprint Specification would need to be layered (e.g., HW, networking, virtualization layers etc etc) and would allow one to do exactly what you described above (Openstack-x86HW-Ubuntu-

 

NoSDNCtrl-v1 OR K8S-x86HW-Ubuntu-OVN-SRIOVCtrl-v1 etc in the same Blueprint)

 

>>Subsequent releases of Akraino for a given Blueprint would add options that could be chosen to form the Blueprint’s Specification

>>The individual functions/plugins/HW in a precise Blueprint’s Specification would be selected from the Blueprint Specification Template.

>>The Blueprint Specification Template would contain all the options supported for a given Blueprint at a given Akraino release.

 

  1. 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?

 

>>We have to support different OS versions and distros in different PODs for sure but should one POD support a mix in the (single) POD?

>>Technically it could but I feel it’ll make the definition and management extremely complex

>>But in forming the definition of a blueprint we should consider it for future as we may then want to structure that definition to support in future multiple options of the same component.

 

  1. Any support for new site level orchestrator requires new blueprint.  Yes?

 

  1. Any support for new SDN controller requires new blueprint. Yes?

 

 

>>I don’t think so if an SDN controller is a plugin option within the Blueprint’s Specification. If not then yes.

>>I could deploy openstack in a Network Cloud Blueprint by selecting different controllers from the set of controller options (e.g. neutron without a controller, ODL or TitaniumFabric controller etc – assuming all were available and tested in a given Akraino release of the ‘Network Cloud’ Blueprint)

 

  1. Any support for new fabric switches requires new blueprint. Yes?

 

>>I wouldn’t assume so by default

>>Let’s say for example a blueprint + spec require L2 only between deployed HW and used only MAC learning – changing the fabric switches out doesn’t have to change the deployment of the POD if the two switches have the same capability.

>>The key question is is the switch fabric managed by the LCM and deployment tools of the Blueprint? If so then you’d need to at least have an option for the different switches in the Blueprint Specification (or have a different Blueprint)

 

  1. Any addition of additional SW packages to NFVI requires new blueprint. Yes?

 

>>Again don’t think so – this will explode the number of Blueprints

>>A different selection of functionalities from those support in a given the Blueprint Specification Template for a given Akraino release would allow one to deploy different SW within the same Blueprint

>>BUT the same question arises about mixing in the same POD deployed by a given Blueprint + Specification as you raised for the OS mixing

>>Think we need more discussion here

 

  1. 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?

>>I’d see this as a change to the blueprint specification not the blueprint itself – i.e. one selects a different OS SW “plugin’ from the template

 

Just few questions for discussions J

 

Thanks

Srini

 

 


Re: Akraino Charter

Glenn Seiler
 

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

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

 

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

 

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

-glenn

 

 

 

 

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

 

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

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

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

Wenjing

From: Thomas Nadeau

To: main<main@...>

Subject: Re: [akraino] Akraino Charter

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

 

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

 

--Tom

 

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

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

 

Wenjing

 

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

 

 

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

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

 

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

 

-        Functional projects develop functionalities to fill identified gaps.

 

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

 

--Tom

 

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

 

Wenjing

 

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

 

Hi Akraino TSC,

 

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

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

 

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

 

Thanks

Srini

 

 

 


Use cases and Blueprints

Srini
 

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

 

 

41 - 60 of 81