1. main@lists.akraino.org
  2. Messages
   Date   
ONS NA 2019 Un-Conference - Leverage OPNFV Test Frameworks

Trevor Cooper
 

Please note this un-conference discussion on Fri 4/5 15:10

 

Short Description:  Explore opportunities for your LFN project to accelerate development of test frameworks, tools and methods through collaboration with OPNFV.

 

Detailed Description: OPNFV has developed significant functional and performance test assets including frameworks, tools, methods, test cases and test data. For an overview of the OPNFV Test Ecosystem refer to https://docs.opnfv.org/en/stable-gambia/testing/ecosystem/overview.html. The significant investments in OPNFV test projects and related activities could be leveraged by other  LFN projects that require testing of integrated upstream ingredients and platforms. This discussion is to brainstorm about how to reuse existing work and artifacts so that we do not reinvent proverbial wheels in this arena. All ideas and input are welcome!

 

-----------------

 

Un-conference topics: https://wiki.lfnetworking.org/display/LN/Open+Networking+Summit+North+America+2019+-+Un-conference+Topic+Proposals

 

Un-conference schedule https://wiki.lfnetworking.org/display/LN/ONS+NA+2019+Un-Conference+Schedule

 

---------------------

 

For any questions on this or other un-conference topics please contact David McBride dmcbride@...

 

/Trevor
04/05/2019 Akarino TSC F2F

Sujata Tibrewala
 

04/02 & 04/05 TSC F2F Meeting

When:
Tuesday, 2nd April 2018
Friday, 5th  April 2018

Where:
San Francisco Bay Area, Santa Clara, CA (further details to follow) or Zoom Dial In

Organizer:
tsc@...

An RSVP is requested. <link to come soon>

Description:
Additional meeting and agenda details will follow. 
Visit the 04/02 & 04/05 TSC F2F Wiki Page event wiki page for updates.

Meeting Lead: Tina Tsou, Akraino TSC Co-Chair, tina.tsou@...

 

 
Re: Akraino Mail Lists Update - ACTION REQUIRED

Jacqueline Z Cardoso
 

Akraino Community,

Reminder: If you have not done so, please take a minute to subscribe to the new subgroups created for TSC and Technical-Discussions if you would like to be included in those discussions. We will be transitioning all current and future discussions to the appropriate forums and thank you in advance for your cooperation.

If you have any questions, please don't hesitate to reach out.

Thank you,
Jacqueline
Re: [tsc-private] Akraino Blueprint Technical Charter

Margaret Chiosi <margaret.chiosi1@...>
 

+1 like the organization proposal

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 Andrew Wilkinson
Sent: Monday, September 17, 2018 5:10 AM
To: main@lists.akraino.org
Subject: [Akraino Main] FW: [tsc-private] Akraino Blueprint Technical Charter

Resending to main@list.akraino.org as requested by moderator. So some may already seen this - apologies if so.

There is also very interesting suggestion from Frank of a higher level classification i.e. 'Order' to define the target use case (there of course there could be one or more 'Families' of solutions to support that use case).

Again I would like to stress this isn't suggesting or encouraging sprawl to the project - it is quite valid to start with one instance of Family, Genus and Species for a give use case e.g. to support 5G VNF edge deployments - my target is enable a flexible framework to add within the Akraino blueprint framework as time and new releases occur even if we only start with one or two possibilities initially.

Andrew

-----Original Message-----
From: Andrew Wilkinson <andrew.wilkinson@ericsson.com>
Sent: Thursday, September 13, 2018 4:02 PM
To: tsc-voting@lists.akraino.org
Subject: Re: [tsc-private] Akraino Blueprint Technical Charter

As we may be discussing this in multiple forums/email lists so apologies if this is a repeat for some on the this list but sending again to make sure all see it.

I think there are fundamentally 3 levels involved in the inception of new family of PODs to the deployment of an actual physical Akraino POD at an actual site.

3. The lowest is exact and defined by a set of yaml files that build the actual POD deployed to a site. This is down to the number of compute, type of compute, SW versions, names of servers etc etc. If I say change from 3 to 4 compute in a POD this level changes as one or more of the yaml files changes

Then the first two levels would be

1. The Blueprint level as the highest level. This is for example a 'Network Cloud' blueprint or the 'StarlingX' blueprint or whatever is approved/offered to the community. Within this characterization the are a number of immutable characteristics that make it that blueprint that blueprint and fundamentally differen to other blueprints e.g. (not i.e.!) use of airship, installation of OpenStack etc.

2. The Blueprint Specification. This allows variation of major components of the blueprint e.g. the use of say Dell over HP compute, the use of Ubuntu over say Centos etc etc. It's important to note there could be just one specification or a number depending on a given blueprint.

I gave these names in keeping with the opensource community's love of animal themes and borrowed from the Linnaeus biological taxonomy structure : Blueprint Family (1) , Genus (2) and Species (3)

We should review this as a proposal at the next blueprint session.

Andrew

-----Original Message-----
From: tsc-voting@lists.akraino.org <tsc-voting@lists.akraino.org> On Behalf Of Takeshi Kuwahara
Sent: Wednesday, September 12, 2018 7:49 AM
To: tsc-voting@lists.akraino.org
Subject: Re: [tsc-private] Akraino Blueprint Technical Charter

Dear team,

A blueprint specification template should support various use cases and requirements. On the other hand, it is not always easy to list up all the possible use cases and requirements to be supported by a blueprint when it's proposed. Also, it is necessary to energize the community by providing a mechanism that is easy to accept various proposals.
Therefore, the community needs to be able to update existing blueprint specification templates when necessary. Major triggers of such update are:

A) Major/minor version update of a software component included in a given blueprint specification template. Example: Ubuntu 18.04.1 -> 18.04.2

B) Newer generation of a hardware component included in a given blueprint specification template. Example: Dell R740 -> R750

C) Proposal of new use cases and requirements/test cases which could be solved by updating an existing blueprint specification template through feature updates and/or template options updates. Example: Lower latency Network Cloud

Software updates (A) can be verified and incorporated as the update to the existing blueprint spec template through an appropriate CI/CD mechanism.

Hardware renewal (B) can also be done in the same way if anyone can contribute to bring those to CI/CD labs.

New proposals (C) can be handled in the following way:

1) Contributor who are going to propose it needs to explain clear use
case(s) and its requirements (i.e. POD and test cases).

2) If the community has an existing blueprint specification template (here assume BPT-A 1.0) which can solve some use cases and requirements that is not too far from the proposed ones, then the community can treat the proposal as potential update of the existing blueprint spec template (BPT-A 1.1 or 2.0, depending of versioning policy). If not, the community should consider to make another blueprint spec template (BPT-B 1.0).

The point is that we should not make too many numbers of blueprint spec templates for the sake of the community maintenance and market value.
Therefore, new proposal needs to be compared to the existing ones and only when it’s not close at all to any, we can consider making new blueprint spec templates.


Thanks,

- Takeshi


On 2018/09/04 23:53, Tina Tsou wrote:
Dear team,

Draft of Akraino blueprint technical charter is attached, and the link
is here.

https://docs.google.com/document/d/1SxqUV0VnfbU_M3YyBZh6WE6_eRd_gm3SYI
RiutXDz6M

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.
--
---
Takeshi KUWAHARA
<kuwahara.takeshi@lab.ntt.co.jp>
Network Technology Labs,
NTT
FW: [tsc-private] Akraino Blueprint Technical Charter

Andrew Wilkinson
 

Resending to main@list.akraino.org as requested by moderator. So some may already seen this - apologies if so.

There is also very interesting suggestion from Frank of a higher level classification i.e. 'Order' to define the target use case (there of course there could be one or more 'Families' of solutions to support that use case).

Again I would like to stress this isn't suggesting or encouraging sprawl to the project - it is quite valid to start with one instance of Family, Genus and Species for a give use case e.g. to support 5G VNF edge deployments - my target is enable a flexible framework to add within the Akraino blueprint framework as time and new releases occur even if we only start with one or two possibilities initially.

Andrew

-----Original Message-----
From: Andrew Wilkinson <andrew.wilkinson@ericsson.com>
Sent: Thursday, September 13, 2018 4:02 PM
To: tsc-voting@lists.akraino.org
Subject: Re: [tsc-private] Akraino Blueprint Technical Charter

As we may be discussing this in multiple forums/email lists so apologies if this is a repeat for some on the this list but sending again to make sure all see it.

I think there are fundamentally 3 levels involved in the inception of new family of PODs to the deployment of an actual physical Akraino POD at an actual site.

3. The lowest is exact and defined by a set of yaml files that build the actual POD deployed to a site. This is down to the number of compute, type of compute, SW versions, names of servers etc etc. If I say change from 3 to 4 compute in a POD this level changes as one or more of the yaml files changes

Then the first two levels would be

1. The Blueprint level as the highest level. This is for example a 'Network Cloud' blueprint or the 'StarlingX' blueprint or whatever is approved/offered to the community. Within this characterization the are a number of immutable characteristics that make it that blueprint that blueprint and fundamentally differen to other blueprints e.g. (not i.e.!) use of airship, installation of OpenStack etc.

2. The Blueprint Specification. This allows variation of major components of the blueprint e.g. the use of say Dell over HP compute, the use of Ubuntu over say Centos etc etc. It's important to note there could be just one specification or a number depending on a given blueprint.

I gave these names in keeping with the opensource community's love of animal themes and borrowed from the Linnaeus biological taxonomy structure : Blueprint Family (1) , Genus (2) and Species (3)

We should review this as a proposal at the next blueprint session.

Andrew

-----Original Message-----
From: tsc-voting@lists.akraino.org <tsc-voting@lists.akraino.org> On Behalf Of Takeshi Kuwahara
Sent: Wednesday, September 12, 2018 7:49 AM
To: tsc-voting@lists.akraino.org
Subject: Re: [tsc-private] Akraino Blueprint Technical Charter

Dear team,

A blueprint specification template should support various use cases and requirements. On the other hand, it is not always easy to list up all the possible use cases and requirements to be supported by a blueprint when it's proposed. Also, it is necessary to energize the community by providing a mechanism that is easy to accept various proposals.
Therefore, the community needs to be able to update existing blueprint specification templates when necessary. Major triggers of such update are:

A) Major/minor version update of a software component included in a given blueprint specification template. Example: Ubuntu 18.04.1 -> 18.04.2

B) Newer generation of a hardware component included in a given blueprint specification template. Example: Dell R740 -> R750

C) Proposal of new use cases and requirements/test cases which could be solved by updating an existing blueprint specification template through feature updates and/or template options updates. Example: Lower latency Network Cloud

Software updates (A) can be verified and incorporated as the update to the existing blueprint spec template through an appropriate CI/CD mechanism.

Hardware renewal (B) can also be done in the same way if anyone can contribute to bring those to CI/CD labs.

New proposals (C) can be handled in the following way:

1) Contributor who are going to propose it needs to explain clear use
case(s) and its requirements (i.e. POD and test cases).

2) If the community has an existing blueprint specification template (here assume BPT-A 1.0) which can solve some use cases and requirements that is not too far from the proposed ones, then the community can treat the proposal as potential update of the existing blueprint spec template (BPT-A 1.1 or 2.0, depending of versioning policy). If not, the community should consider to make another blueprint spec template (BPT-B 1.0).

The point is that we should not make too many numbers of blueprint spec templates for the sake of the community maintenance and market value.
Therefore, new proposal needs to be compared to the existing ones and only when it’s not close at all to any, we can consider making new blueprint spec templates.


Thanks,

- Takeshi


On 2018/09/04 23:53, Tina Tsou wrote:
Dear team,

Draft of Akraino blueprint technical charter is attached, and the link
is here.

https://docs.google.com/document/d/1SxqUV0VnfbU_M3YyBZh6WE6_eRd_gm3SYI
RiutXDz6M

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.
--
---
Takeshi KUWAHARA
<kuwahara.takeshi@lab.ntt.co.jp>
Network Technology Labs,
NTT

?
Akraino Blueprints and Blueprint Specification v5 - Ericsson proposal.pptx

Re: Use cases and Blueprints

Wenjing Chu <Wenjing.Chu@...>
 

Looks like the main@ list is rejecting new topics now. I guess the intention is moving all these to:

technical-discuss@...

or

tsc@...

 

Right now, these new groups have very few subscribers. You will need to go to https://lists.akraino.org to sign up. It appears NOT automatic.

 

In any case, my intended email thread was: (Apologies for skirting rules here – since the new groups aren’t adequately up running with subscribers yet.)

 

 

For folks going to ONS-EU Amsterdam Sept 25-27.

 

I have created a new Unconference session: “Edge Stack Discussion for Cloud Edge and IoT”.

It’s a good opportunity to bring together people from several open source projects working in the edge space during ONS. I’d love to see you all join this session.

 

Add your names to:

https://wiki.lfnetworking.org/display/LN/Open+Networking+Summit+Europe+2018+-+Unconference+Topic+Proposals

 

Regards

Wenjing

 

 

From: main@... [mailto:main@...] On Behalf Of KATHIRVEL, KANDAN
Sent: Friday, September 14, 2018 10:43 AM
To: Glenn Seiler <Glenn.seiler@...>; Margaret Chiosi (A) <margaret.chiosi1@...>; main@...
Subject: Re: [Akraino Main] Use cases and Blueprints

 

We (TSC) are putting together a draft with all the terminologies this community to use and a process around it. As we promised in the yesterday’s community call, we will review the draft on next Thursday 11 ET @ community call. The intent is to baseline the version by this month end with TSC approval.

I encourage everyone in the community to join next community call to participate in the discussion.

-Kandan

 

 

From: <main@...> on behalf of Glenn Seiler <Glenn.seiler@...>
Date: Friday, September 14, 2018 at 11:41 AM
To: Margaret Chiosi <margaret.chiosi1@...>, "main@..." <main@...>
Subject: Re: [Akraino Main] Use cases and Blueprints

 

I may have missed some threads, but I thought we were discussing

1)     Integration Blueprints (architecture)

2)     Functional Blueprints  (components)

 

I agree with some of the other comments that we risk spreading or diluting the definition of Blueprint to broadly and it can be very confusing.

I support the idea that blueprints are pretty specific, not just defining components that are integrated, but how they are intended to be used and deployed.

I’m not sure this would apply to an individual component (or functional) blueprint.

 

-glenn

 

From: main@... [mailto:main@...] On Behalf Of Margaret Chiosi
Sent: Thursday, September 13, 2018 8:22 AM
To: main@...
Subject: Re: [Akraino Main] Use cases and Blueprints

 

I thought in email folks were ok with the following types of blueprint:
1. Architecture
2. components (Physical/virtual) supporting a specific 'use case'
3. Test

Re: Use cases and Blueprints

KATHIRVEL, KANDAN
 

We (TSC) are putting together a draft with all the terminologies this community to use and a process around it. As we promised in the yesterday’s community call, we will review the draft on next Thursday 11 ET @ community call. The intent is to baseline the version by this month end with TSC approval.

I encourage everyone in the community to join next community call to participate in the discussion.

-Kandan

 

 

From: <main@...> on behalf of Glenn Seiler <Glenn.seiler@...>
Date: Friday, September 14, 2018 at 11:41 AM
To: Margaret Chiosi <margaret.chiosi1@...>, "main@..." <main@...>
Subject: Re: [Akraino Main] Use cases and Blueprints

 

I may have missed some threads, but I thought we were discussing

  1. Integration Blueprints (architecture)
  2. Functional Blueprints  (components)

 

I agree with some of the other comments that we risk spreading or diluting the definition of Blueprint to broadly and it can be very confusing.

I support the idea that blueprints are pretty specific, not just defining components that are integrated, but how they are intended to be used and deployed.

I’m not sure this would apply to an individual component (or functional) blueprint.

 

-glenn

 

From: main@... [mailto:main@...] On Behalf Of Margaret Chiosi
Sent: Thursday, September 13, 2018 8:22 AM
To: main@...
Subject: Re: [Akraino Main] Use cases and Blueprints

 

I thought in email folks were ok with the following types of blueprint:
1. Architecture
2. components (Physical/virtual) supporting a specific 'use case'
3. Test

Re: Use cases and Blueprints

Glenn Seiler
 

I may have missed some threads, but I thought we were discussing

1)      Integration Blueprints (architecture)

2)      Functional Blueprints  (components)

 

I agree with some of the other comments that we risk spreading or diluting the definition of Blueprint to broadly and it can be very confusing.

I support the idea that blueprints are pretty specific, not just defining components that are integrated, but how they are intended to be used and deployed.

I’m not sure this would apply to an individual component (or functional) blueprint.

 

-glenn

 

From: main@... [mailto:main@...] On Behalf Of Margaret Chiosi
Sent: Thursday, September 13, 2018 8:22 AM
To: main@...
Subject: Re: [Akraino Main] Use cases and Blueprints

 

I thought in email folks were ok with the following types of blueprint:
1. Architecture
2. components (Physical/virtual) supporting a specific 'use case'
3. Test

Re: Use cases and Blueprints

Margaret Chiosi <margaret.chiosi1@...>
 

Actually I would have thought integration meant ‘testing’ and functional meant architecture J

But as long as we define the different blueprints and the definition of them.

 

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: Seiler, Glenn [mailto:glenn.seiler@...]
Sent: Thursday, September 13, 2018 2:43 PM
To: Margaret Chiosi (A) <margaret.chiosi1@...>; main@...
Subject: RE: [Akraino Main] Use cases and Blueprints

 

I may have missed some threads, but I thought we were discussing

1)      Integration Blueprints (architecture)

2)      Functional Blueprints  (components)

 

I agree with some of the other comments that we risk spreading or diluting the definition of Blueprint to broadly and it can be very confusing.

I support the idea that blueprints are pretty specific, not just defining components that are integrated, but how they are intended to be used and deployed.

I’m not sure this would apply to an individual component (or functional) blueprint.

 

-glenn

 

From: main@... [mailto:main@...] On Behalf Of Margaret Chiosi
Sent: Thursday, September 13, 2018 8:22 AM
To: main@...
Subject: Re: [Akraino Main] Use cases and Blueprints

 

I thought in email folks were ok with the following types of blueprint:
1. Architecture
2. components (Physical/virtual) supporting a specific 'use case'
3. Test

Re: Use cases and Blueprints

Margaret Chiosi <margaret.chiosi1@...>
 

I will be surprised if we can come up with one functional set of components we all agree on based on my OPNFV/ONAP experience.

But we can try.

 

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: Andrew Wilkinson [mailto:andrew.wilkinson@...]
Sent: Thursday, September 13, 2018 11:40 AM
To: Margaret Chiosi (A) <margaret.chiosi1@...>; main@...
Subject: RE: [Akraino Main] Use cases and Blueprints

 

 

I wouldn’t see a Test definition (3) as a ‘blueprint’.

 

Nor would I see specific functional components (2) developed by the Akraino community as ‘blueprints’ either.

 

I think using the term blueprint for everything tends to make the term too broad. The term blueprint in common parlance is taken to mean the definition of how to build something (e.g. a building – a house or a shed etc). I could of course be expanded to encompass more (like a test blueprint) but would suggest we keep Akraino blueprints to be more specific and not include  functionality or test schedules.

 

Rather I propose a blueprint be used to classify a set of options that cab result in distinct POD deployments. The term ‘Network Clod blueprint’ would be used as such.

 

Andrew

From: main@... <main@...> On Behalf Of Margaret Chiosi
Sent: Thursday, September 13, 2018 4:22 PM
To: main@...
Subject: Re: [Akraino Main] Use cases and Blueprints

 

I thought in email folks were ok with the following types of blueprint:
1. Architecture
2. components (Physical/virtual) supporting a specific 'use case'
3. Test

Re: Akraino Mail Lists Update - ACTION REQUIRED

Andrew Grimberg
 

On 09/13/2018 08:37 AM, fzdarsky@redhat.com wrote:
On Thu, Sep 13, 2018 at 5:03 PM Jacqueline Serafin
<jserafin@linuxfoundation.org> wrote:
--snip--

The main@lists.akraino.org list will remain available but we recommend using this list extremely sparingly, for top-level milestone or critical announcements as the messages will hit all subscribers of all subgroups.
Would it make sense to rename this to "announce@..." then?
My understanding of the underlying list platform we're using is that the
main list can't be renamed.

-Andy-

--
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation

?
signature.asc

Re: Use cases and Blueprints

fzdarsky@...
 

On Thu, Sep 13, 2018 at 5:39 PM Andrew Wilkinson
<andrew.wilkinson@ericsson.com> wrote:



I wouldn’t see a Test definition (3) as a ‘blueprint’.



Nor would I see specific functional components (2) developed by the Akraino community as ‘blueprints’ either.



I think using the term blueprint for everything tends to make the term too broad. The term blueprint in common parlance is taken to mean the definition of how to build something (e.g. a building – a house or a shed etc). I could of course be expanded to encompass more (like a test blueprint) but would suggest we keep Akraino blueprints to be more specific and not include functionality or test schedules.
I tend to agree. The term "blueprint" in Akraino is already confusing
enough, even without using it also in the OpenStack Blueprint kind of
sense ;)




Rather I propose a blueprint be used to classify a set of options that cab result in distinct POD deployments. The term ‘Network Clod blueprint’ would be used as such.



Andrew

From: main@lists.akraino.org <main@lists.akraino.org> On Behalf Of Margaret Chiosi
Sent: Thursday, September 13, 2018 4:22 PM
To: main@lists.akraino.org
Subject: Re: [Akraino Main] Use cases and Blueprints



I thought in email folks were ok with the following types of blueprint:
1. Architecture
2. components (Physical/virtual) supporting a specific 'use case'
3. Test



--
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 Mail Lists Update - ACTION REQUIRED

fzdarsky@...
 

On Thu, Sep 13, 2018 at 6:25 PM Andrew Grimberg
<agrimberg@linuxfoundation.org> wrote:

On 09/13/2018 08:37 AM, fzdarsky@redhat.com wrote:
On Thu, Sep 13, 2018 at 5:03 PM Jacqueline Serafin
<jserafin@linuxfoundation.org> wrote:
--snip--

The main@lists.akraino.org list will remain available but we recommend using this list extremely sparingly, for top-level milestone or critical announcements as the messages will hit all subscribers of all subgroups.
Would it make sense to rename this to "announce@..." then?
My understanding of the underlying list platform we're using is that the
main list can't be renamed.
Understood, np. Sorry for the noise.


-Andy-

--
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation

--
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: Use cases and Blueprints

Andrew Wilkinson
 

 

I wouldn’t see a Test definition (3) as a ‘blueprint’.

 

Nor would I see specific functional components (2) developed by the Akraino community as ‘blueprints’ either.

 

I think using the term blueprint for everything tends to make the term too broad. The term blueprint in common parlance is taken to mean the definition of how to build something (e.g. a building – a house or a shed etc). I could of course be expanded to encompass more (like a test blueprint) but would suggest we keep Akraino blueprints to be more specific and not include  functionality or test schedules.

 

Rather I propose a blueprint be used to classify a set of options that cab result in distinct POD deployments. The term ‘Network Clod blueprint’ would be used as such.

 

Andrew

From: main@... <main@...> On Behalf Of Margaret Chiosi
Sent: Thursday, September 13, 2018 4:22 PM
To: main@...
Subject: Re: [Akraino Main] Use cases and Blueprints

 

I thought in email folks were ok with the following types of blueprint:
1. Architecture
2. components (Physical/virtual) supporting a specific 'use case'
3. Test

Re: Akraino Mail Lists Update - ACTION REQUIRED

fzdarsky@...
 

On Thu, Sep 13, 2018 at 5:03 PM Jacqueline Serafin
<jserafin@linuxfoundation.org> wrote:

Akraino Community,

In order to facilitate future discussions in clearly delineated forums utilizing open source project best practices we have made changes to the mail lists available for this community. Please review below the lists available and ensure you subscribe to the lists you are interested in by adding yourself to the applicable subgroups.

Subgroups Available:

[new] tsc@lists.akraino.org

To be used for top-level technical/governance discussions, TSC agendas/minutes, etc. Open to everyone, not only to TSC members.

[new] technical-discuss@lists.akraino.org

To be used for general technical discussion and questions.


The main@lists.akraino.org list will remain available but we recommend using this list extremely sparingly, for top-level milestone or critical announcements as the messages will hit all subscribers of all subgroups.
Would it make sense to rename this to "announce@..." then?


As the Akraino project grows and scales we can certainly add additional lists but we’d like to first establish a proper foundation and thoughtfully build from there.

If you have any questions, please reach out.

Thank you,

Jacqueline


Jacqueline Serafin
Program Manager
The Linux Foundation
+1 (415) 676-1127 (m)
jserafin@linuxfoundation.org



--
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: Use cases and Blueprints

Margaret Chiosi <margaret.chiosi1@...>
 

I thought in email folks were ok with the following types of blueprint:
1. Architecture
2. components (Physical/virtual) supporting a specific 'use case'
3. Test
Akraino Mail Lists Update - ACTION REQUIRED

Jacqueline Z Cardoso
 

Akraino Community,

In order to facilitate future discussions in clearly delineated forums utilizing open source project best practices we have made changes to the mail lists available for this community. Please review below the lists available and ensure you subscribe to the lists you are interested in by adding yourself to the applicable subgroups.

  • Subgroups Available:
    • [new] tsc@... 
      • To be used for top-level technical/governance discussions, TSC agendas/minutes, etc. Open to everyone, not only to TSC members.
      • To be used for general technical discussion and questions. 

The main@... list will remain available but we recommend using this list extremely sparingly, for top-level milestone or critical announcements as the messages will hit all subscribers of all subgroups. 

As the Akraino project grows and scales we can certainly add additional lists but we’d like to first establish a proper foundation and thoughtfully build from there. 

If you have any questions, please reach out. 

Thank you,

Jacqueline


Jacqueline Serafin
Program Manager
The Linux Foundation
+1 (415) 676-1127 (m)
locked Topics for Akraino community call on September 13th?

Tapio Tallgren <tapio.tallgren@...>
 

Hi all,

We have scheduled the second Akraino community call for Thursday, September 13th. Since a lot of the people who have contributed to the blueprint discussion on the mailing list have conflicting meetings, I would like to hear suggestions for topics.

-Tapio
Re: Akraino Charter

fzdarsky@...
 

On Mon, Sep 10, 2018 at 5:03 PM Srini <srinivasa.r.addepalli@...> wrote:

Hi Frank,

 

On this:

 

“

-        Is Akraino look to build the images/containers? Or limit the scope to installers, starting with Airship? If so, which sister project(s) going to build binary images suitable for Airship?

Could you maybe elaborate why you feel it matters whether building images is part of the project or not?

 

“

I see some projects applying patches (patches that are created in upstream) to their current release instead of taking latest release. This requires capability of building binaries & packages.


So selectively backporting patches from upstream's master into upstream's stable branch. That's something we might want to do in the upstream branch, too, but I can see the need for exceptions to that.
Hope the project can agree on a policy around such selective backporting (vs. carrying out-of-tree patches).
 

 

Even otherwise, there are some upstream projects don’t create binary images or images in a way that is required.

 

For example, Openstack-kolla and Openstack-helm projects can be considered as sister projects to Airship as Kolla project creates container images for each openstack service and pushes them to dockerhub.  Openstak-helm project is the home for helm charts which help in deploying them. I guess Airship installer requires them in containers and helm charts.  

 

Some projects such as libvirtd, ovs, ovs-dpdk, collectd, kubelet, OVN north/south controllers and many more, that are required to be part of the Edge stack, also need to be containerized and have helm charts. Where do we do them? As Akraino or as a sister project?

 

My thinking is that to make Akraino complete integration project, it would need to have capabilities to build the images. 


Agree there may be a need to build images. Should probably be left to the respective Blueprint projects to decide how to build them, as each project may have tooling that's more "native" to them.
 

 

Thoughts?

 

 

 

 

 

What about

 

 

From: main@... [mailto:main@...] On Behalf Of fzdarsky@...
Sent: Friday, September 7, 2018 4:20 AM
To: main@...
Subject: Re: [akraino] Akraino Charter

 

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



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

Srini
 

Hi Frank,

 

On this:

 

“

-        Is Akraino look to build the images/containers? Or limit the scope to installers, starting with Airship? If so, which sister project(s) going to build binary images suitable for Airship?

Could you maybe elaborate why you feel it matters whether building images is part of the project or not?

 

“

I see some projects applying patches (patches that are created in upstream) to their current release instead of taking latest release. This requires capability of building binaries & packages.

 

Even otherwise, there are some upstream projects don’t create binary images or images in a way that is required.

 

For example, Openstack-kolla and Openstack-helm projects can be considered as sister projects to Airship as Kolla project creates container images for each openstack service and pushes them to dockerhub.  Openstak-helm project is the home for helm charts which help in deploying them. I guess Airship installer requires them in containers and helm charts.  

 

Some projects such as libvirtd, ovs, ovs-dpdk, collectd, kubelet, OVN north/south controllers and many more, that are required to be part of the Edge stack, also need to be containerized and have helm charts. Where do we do them? As Akraino or as a sister project?

 

My thinking is that to make Akraino complete integration project, it would need to have capabilities to build the images. 

 

Thoughts?

 

 

 

 

 

What about

 

 

From: main@... [mailto:main@...] On Behalf Of fzdarsky@...
Sent: Friday, September 7, 2018 4:20 AM
To: main@...
Subject: Re: [akraino] Akraino Charter

 

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
1 - 20 of 76