|
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
|
|
|
Wenjing Chu <Wenjing.Chu@...>
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.
-
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
toggle quoted message
Show quoted text
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
|
|
|
On 09/04/2018 12:49 PM, Srini 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.
It is not clear at all whether Akraino is the right owner for the
APIs or not --- many other projects and communities are working on
addressing the pieces of this rather large & diverse puzzle
(ONAP, CNCF/k8s, various projects in OPNFV & OpenStack, etc.
etc.), and IMHO, the last think that we need is more duplication for
the ongoing efforts which would result in even more fragmentation of
the landscape.
So, whenever possible, optimally Akraino would pull from
upstreams like OPNFV does and identify/address the gaps. Obviously
in the cases where there is nothing (or existing approaches are
deemed unsuitable / unfixable after careful consideration),
Akraino could be in good position to resolve.
I am saying the above, as ownership of the APIs does and should
belong to the projects implementing them, not something like
Akraino. If it is identifying, selecting and requesting additions
/ modifications, or Akraino hosted development projects, then that
would be ok. Blueprint for the infrastructure is expected to make
some selections for the projects that go in, so that implicitly
makes some picks on the APIs as well - but that would not make
Akraino "developer" for such cases, more like Endorser / selector.
That said, there is very much confusion between the ONAP edge as
well as Akraino (on both sides) on who is going to do what and
when which should get resolved sooner rather than later, as the
context of the comment was "regional orchestration".
Pasi
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
|
|
|
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
|
|
|
Wenjing Chu <Wenjing.Chu@...>
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
toggle quoted message
Show quoted text
From: main@... [mailto:main@...]
On Behalf Of Thomas Nadeau
Sent: Tuesday, September 04, 2018 1:34 PM
To: main@...
Subject: Re: [akraino] Akraino Charter
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?
-
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
|
|
|
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
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
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?
-
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
|
|
|
Wenjing Chu <Wenjing.Chu@...>
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
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
toggle quoted message
Show quoted text
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
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?
-
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
|
|
|
Cool. I think we are all on the same page now.
--Tom
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
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
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
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?
-
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
|
|
|
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ó
toggle quoted message
Show quoted text
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
|
|
|
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
toggle quoted message
Show quoted text
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
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.
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
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?
-
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
|
|
|
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
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
toggle quoted message
Show quoted text
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
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.
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
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?
-
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
|
|
|
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
toggle quoted message
Show quoted text
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
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
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
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.
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
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?
-
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
|
|
|
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
toggle quoted message
Show quoted text
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
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
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.
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
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?
-
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
|
|
|
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
toggle quoted message
Show quoted text
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
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
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
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.
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
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?
-
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
|
|
|
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
|
|
|
Thank you for discussion on this.
Terminology suggested by Wenjing on categorization (features/functional and integration) seems good to me too.
Thanks
Srini
toggle quoted message
Show quoted text
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
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
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
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.
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
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?
-
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
|
|
|
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
toggle quoted message
Show quoted text
From: main@... [mailto:main@...]
On Behalf Of fzdarsky@...
Sent: Thursday, September 06, 2018 9:33 AM
To: main@...
Subject: Re: [akraino] Akraino Charter
It is confusing, yes. And it confirms that we've not made explicit whether Akraino is mainly an integration, development, or specification/standardization project.
I hope we can agree that Akraino is an *integration project*, whose mission it is (paraphrasing from Charter) to make it easier for our users to design/customize, build, and operate edge stacks for their given use case.
And no, this does not exclude us doing software development, e.g. testing tools&frameworks, adding auxiliary functionality for which no suitable upstream exists yet, etc.
And no, this does not exclude us doing specifications, e.g. of Edge APIs where no suitable APIs exist yet.
All it says is that such software development and specification work would be subordinate to the goal of enabling integration.
Secondly, I hope we can further agree that Akraino's goal is to
*enable* integration, *not prescribe* a given integration.
Means, if our goal is to enable Akraino users to build an edge stack for Industrial IoT, Network Access Edge, etc., we'll ensure that the upstream components have the required functionality for those use cases and that this functionality
also works end-to-end to meet those use cases, e.g. CPU resource management or GPU/TPU device management across app, middleware, Kubernetes and OpenStack. Or cross-stack operations.
We are (I hope) not trying to create "Akraino distributions" and spend large amounts of engineering resources on redoing integration, stabilization, hardening, etc. work that's already done by upstream projects and downstream products.
In that sense, I kind of disagree with calling Akraino a "mid-stream" project, because that would imply an expectation that downstream products that take source from upstreams like Kubernetes *via* Akraino instead of directly from them...
which only makes sense if we envision to fork the upstreams or extend them in ways not acceptable to the upstreams...
On Wed, Sep 5, 2018 at 10:15 PM <ildiko@...> wrote:
Hi,
I got a little confused on one part of the description below. What does “is also a home for Edge related open source projects for the functionality where there is a gap in the open source community” mean exactly?
Is Akraino a mid-stream project meaning that beyond integration and testing it will also identify gaps and work together with other communities to address them in the open source projects? Or saying it is the home for those gaps means that it would be Akraino
hosting the code for that missing functionality?
Thanks,
Ildikó
> On 2018. Sep 4., at 11:49, Srini <srinivasa.r.addepalli@...> wrote:
>
> Hi Akraino TSC,
>
> In the last developer conference, TSC has taken an AI to come out with the Akraino charter definition.
> Much of the discussion on last developer conference is mostly about blueprints, except for one break-out session.
>
> In regional orchestration, Edge API and AI breakout session, we talked about the need for them and the consensus is that Akraino project is the right place to develop them. In one of the Kandan’s presentation, it was clear that Akraino is not only for developing
blueprints for various use cases, but is also a home for Edge related open source projects for the functionality where there is a gap in the open source community. Please consider making the Akraino charter clear on the aspect of development projects to avoid
any confusion.
>
> Thanks
> Srini
>
>
>
>
--
Frank Zdarsky | NFV&SDN Technology Strategy, Office of the CTO | Red Hat
e: fzdarsky@... | irc: fzdarsky@freenode | m: +49 175 82 11 64 4
|
|
|
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ó
toggle quoted message
Show quoted text
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
|
|
|
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
toggle quoted message
Show quoted text
-----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
>
|
|
|
Tina Tsou
Dear Srini et al,
Good questions.
In my mind, Akraino is Integration + Development project.
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.
|
|
|
