|
Re: Akraino TSC Elections 2022-2023
Kendall Waters Perez
Hi everyone,
We have extended the nomination deadline to Tuesday, September 20. All Akraino Community Active Contributors are eligible to vote, but they must self register on this page by September 20. The basic requirement to be considered an Active Contributor is that you have made "twenty (20) or more measurable contributions as assessed by the TSC during the previous 12-month period, inclusive of code merged, code reviews performed, wiki page edits, or JIRA activities.” If you want to be on the TSC, there is a column to self nominate for this. There are a couple of rules around being a member of the TSC and they are covered here (section 4.4.2). But we can have up to 20 members on the TSC. Please let me know if you have any questions. Cheers, Kendall |
|
|
|
Akraino TSC Elections 2022-2023
Kendall Waters Perez
Hello everyone,
As you have probably heard the Akraino TSC elections are coming up. All Akraino Community Active Contributors are eligible to vote, but they must self register on this page by September 9, 2022. The basic requirement to be considered an Active Contributor is that you have made "twenty (20) or more measurable contributions as assessed by the TSC during the previous 12-month period, inclusive of code merged, code reviews performed, wiki page edits, or JIRA activities.” Active Contributors are the backbone of Akraino, so please help us out by registering and then voting for the TSC. To make it a little easier to determine if you are eligible, I have attached a spreadsheet that covers activity from the past year. If you want to be on the TSC, there is a column to self nominate for this. There are a couple of rules around being a member of the TSC and they are covered here (section 4.4.2). But we can have up to 20 members on the TSC. Please let me know if you have any questions. Thanks, Kendall --- Kendall Waters Perez Senior Project Coordinator | Magma, LF Edge, & FINOS The Linux Foundation +1 (469) 585-5165 |
|
|
|
Akraino TSC Elections 2021-2022 Nomination Deadline Extended
Kendall Waters Perez
Hi everyone,
We have extended the deadline for self nominations for the 2021-2022 Akraino TSC election to September 7. All Akraino Community Active Contributors are eligible to vote, but they must self register on this page. The basic requirement to be considered an Active Contributor is that you have made "twenty (20) or more measurable contributions as assessed by the TSC during the previous 12-month period, inclusive of code merged, code reviews performed, wiki page edits, or JIRA activities.” Active Contributors are the backbone of Akraino, so please help us out by registering and then voting for the TSC. To make it a little easier to determine if you are eligible, I have attached a spreadsheet that covers activity from the past year. Please fill in this information in the table when you self nominate. Thanks! Kendall |
|
|
|
Re: Akraino TSC Elections 2021-2022
Kendall Waters Perez
Hmmm, that is odd. Here is the link to the page: https://wiki.akraino.org/display/AK/TSC+Member+Election+2021-2022
toggle quoted message
Show quoted text
Cheers, Kendall
|
|
|
|
Re: Akraino TSC Elections 2021-2022
Kendall Waters Perez
Hi everyone,
During the TSC meeting today, we have decided to extend the self nominations deadline to next Wednesday, September 1. Akraino Community Active Contributors are eligible to vote, but they must self register on this page.The basic requirement to be considered an Active Contributor is that you have made "twenty (20) or more measurable contributions as assessed by the TSC during the previous 12-month period, inclusive of code merged, code reviews performed, wiki page edits, or JIRA activities." Active Contributors are the backbone of Akraino, so please help us out by registering and then voting for the TSC. To make it a little easier to determine if you are eligible, I have attached a spreadsheet that covers activity from the past year. If you want to be on the TSC, there is a column to self nominate for this. There are a couple of rules around being a member of the TSC and they are covered here (section 4.4.2). But we can have up to 20 members on the TSC. Links: Active Contributors form TSC and election part of the Technical Community Document If you have any questions, please reach out to me. Cheers, Kendall |
|
|
|
Re: Akraino TSC Elections 2021-2022
Kendall Waters Perez
Hi everyone,
Friendly reminder that end of day tomorrow, August 24 is the deadline to self nominate/register yourself to either run for a seat on the Akraino TSC or to be able to vote in the election. Akraino Community Active Contributors are eligible to vote, but they must self register on this page by August 24, 2021. The basic requirement to be considered an Active Contributor is that you have made "twenty (20) or more measurable contributions as assessed by the TSC during the previous 12-month period, inclusive of code merged, code reviews performed, wiki page edits, or JIRA activities." Active Contributors are the backbone of Akraino, so please help us out by registering and then voting for the TSC. To make it a little easier to determine if you are eligible, I have attached a spreadsheet that covers activity from the past year. If you want to be on the TSC, there is a column to self nominate for this. There are a couple of rules around being a member of the TSC and they are covered here (section 4.4.2). But we can have up to 20 members on the TSC. Links: Active Contributors form TSC and election part of the Technical Community Document If you have any questions, please reach out to me. Thanks! Kendall |
|
|
|
Akraino TSC Elections 2021-2022
Kendall Waters Perez
Hello everyone,
As you have probably heard the Akraino TSC elections are coming up. All Akraino Community Active Contributors are eligible to vote, but they must self register on this page by August 24, 2021. The basic requirement to be considered an Active Contributor is that you have made "twenty (20) or more measurable contributions as assessed by the TSC during the previous 12-month period, inclusive of code merged, code reviews performed, wiki page edits, or JIRA activities." Active Contributors are the backbone of Akraino, so please help us out by registering and then voting for the TSC. To make it a little easier to determine if you are eligible, I have attached a spreadsheet that covers activity from the past year. If you want to be on the TSC, there is a column to self nominate for this. There are a couple of rules around being a member of the TSC and they are covered here (section 4.4.2). But we can have up to 20 members on the TSC. Links: Active Contributors form TSC and election part of the Technical Community Document Thanks, Kendall |
|
|
|
ONS NA 2019 Un-Conference - Leverage OPNFV Test Frameworks
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: Where: Organizer: An RSVP is requested. <link to come soon> Description:
|
|
|
|
Re: Akraino Mail Lists Update - ACTION REQUIRED
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
toggle quoted message
Show quoted text
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 -----Original Message-----
From: main@... [mailto:main@...] On Behalf Of Andrew Wilkinson Sent: Monday, September 17, 2018 5:10 AM To: main@... Subject: [Akraino Main] FW: [tsc-private] Akraino Blueprint Technical Charter Resending to main@... 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@...> Sent: Thursday, September 13, 2018 4:02 PM To: tsc-voting@... 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@... <tsc-voting@...> On Behalf Of Takeshi Kuwahara Sent: Wednesday, September 12, 2018 7:49 AM To: tsc-voting@... 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,-- --- Takeshi KUWAHARA <kuwahara.takeshi@...> Network Technology Labs, NTT |
|
|
|
FW: [tsc-private] Akraino Blueprint Technical Charter
Resending to main@... as requested by moderator. So some may already seen this - apologies if so.
toggle quoted message
Show quoted text
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@...> Sent: Thursday, September 13, 2018 4:02 PM To: tsc-voting@... 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@... <tsc-voting@...> On Behalf Of Takeshi Kuwahara Sent: Wednesday, September 12, 2018 7:49 AM To: tsc-voting@... 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,-- --- Takeshi KUWAHARA <kuwahara.takeshi@...> Network Technology Labs, NTT |
|
|
|
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: or
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:
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@...>
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
I thought in email folks were ok with the following types of blueprint: |
|
|
|
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@...>
I may have missed some threads, but I thought we were discussing
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: |
|
|
|
Re: 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: |
|
|
|
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 +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
I thought in email folks were ok with the following types of blueprint: |
|
|
|
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 +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
I thought in email folks were ok with the following types of blueprint: |
|
|
|
Re: Akraino Mail Lists Update - ACTION REQUIRED
On 09/13/2018 08:37 AM, fzdarsky@... wrote:
On Thu, Sep 13, 2018 at 5:03 PM Jacqueline Serafin--snip-- My understanding of the underlying list platform we're using is that theThe main@... list will remain available but we recommend using this list extremely sparingly, for top-level milestone or critical announcements as the messages will hit all subscribers of all subgroups.Would it make sense to rename this to "announce@..." then? main list can't be renamed. -Andy- -- Andrew J Grimberg Manager Release Engineering The Linux Foundation |
|
|
|
Re: Use cases and Blueprints
fzdarsky@...
On Thu, Sep 13, 2018 at 5:39 PM Andrew Wilkinson
<andrew.wilkinson@...> wrote: 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 ;)
-- 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 Mail Lists Update - ACTION REQUIRED
fzdarsky@...
On Thu, Sep 13, 2018 at 6:25 PM Andrew Grimberg
<agrimberg@...> wrote: Understood, np. Sorry for the noise.
-- Frank Zdarsky | NFV&SDN Technology Strategy, Office of the CTO | Red Hat e: fzdarsky@... | irc: fzdarsky@freenode | m: +49 175 82 11 64 4 |
|
|
