Hi,
I've read through all the messages on this thread this afternoon,
and have a few things to add from my past experiences with open source projects
that might help level set things and also help clarify the confusion that I
sense some people are experiencing in why this combined architecture isn't
moving forward as swiftly as some would like it to. In my opinion, the answer
to this is how open source projects often do not easily accept top-down
management approaches, and how they more typically respond. In this case, an
architecture has been created that is now shown to projects with the
expectation that they will comply with it - whether or not the subordinate
project agrees with the architecture, or has the time to do so. It is also
important to observe that the merged architecture, objectively speaking is a
*desired* architecture; it is not a picture of the existing project components.
That is, it is one to aspire to at some point in the future, and not
necessarily as part of the next release. It is this specific point that is
giving people the most heartburn: the prospect of this picture not becoming
reality in the next release.
The reality is that the task of getting the subordinate projects to retool
themselves in order to go along with a unified architecture is more challenging
than writing an architectural document and telling the projects to follow it.
I know many in this project would like the process here to be that
straightforward, but it is turning out once again to not be. Understanding why
and embracing this reality is the key to moving this project forward.
Constituent projects need to get working and figure out how they will implement
the merges in their code bases, and then figure out when/how this will be
scheduled in the master release schedule for the project. This has to happen
before people start building any new functionality including that that is
likely needed to address the desired merged architecture for a number of
components. No amount of wishful thinking or mandates is going to change this.
I say this because I am observing that right now there are still discussions
within projects about how to go about addressing their backlogs. This tells me
that the blocking, tackling and scaffolding needs to be setup for projects to
function before we talk about other things. This is an indication that it
might just be a bit early to be asking projects to figure out how to exist
within a merged architecture - or pay attention to the details of one. It might
also turn out that after a phase of implementation, that the system
architecture needs to be different that is postulated in the desired merged
architecture. Its nice to start with a nice and detailed architectural plan
for what everything is supposed to look like at the end of a project, but we
have to be patient in how we get there and also understand that in modern
software engineering, is rare to have it all figured out a priori.
With that in mind, it appears that as of now that it is going to be difficult
to see a way forward where all the lego blocks come together from each project,
have been rewritten to accommodate the desired merged architecture and
requirements, and do so in time for the next release. That also assumes that
all of the projects agree on where they are going - which from what this thread
sounds like is not exactly the case right now. One way less resistive path
forward is to start by agreeing to disagree on certain portions of the
architecture, while recognizing the portions of the architecture that do enjoy
buy-in from a significant number of people. Next, do what we did in past
projects: release multiple options simultaneously and let derivatives repackage
as necessary downstream until such time as the developers are pushed in one way
or the other. If some projects do have time to start down the road of the
desired architecture, then great, but if they do not accept that and work on
simply getting them out in as stable a form as possible. To this end, perhaps
focus the integration teams on making sure that all the components build and
can be tested to some degree and that the major functional "core" components
work. Then as projects gradually build better successor components in the mold
of the desired architecture, the old ones will be deprecated.
This is decidedly not as clean as some would like it to be and will take time
and patience for sure, but in the end I think will bring valuable
implementation and deployment feedback to the party and that after some
iteration and feedback, will help projects make better decisions on what to
build going forward. It will also result in a project and components that are
built to meet the goals of the project, which is what I hope and think we are
all after.
--Tom
From: [email protected]
[mailto:[email protected]] On Behalf Of Alla Goldner
Sent: Saturday, July 22, 2017 1:56 AM
To: Pasi Vaananen <[email protected]>; [email protected]
Cc: onap-tsc <[email protected]>
Subject: Re: [onap-discuss] Architecture Progress
Hi Pasi, Jamil, Chris, all,
I fully agree with Pasi's view.
When we started this work ,the assumption was that whatever our merged
architecture will look like internally, we should deliver a single set of
interfaces between the VNFs and ONAP.
And this is not what we are having right now with R1 proposed architecture.
Also, indeed, if we allow interfaces' divergence for R1, it is going to be hard
to reverse later. One possible outcome is that some of VNF vendors would want
to wait until the divergences are resolved. The other possible outcome is that
we continue proceeding with 2 different tracks within ONAP - one coming from
Open-O and the other one coming from ecomp, and each one of VNF vendors making
a decision which track they want/need to support, in some cases having a need
to support both thus doubling the effort. The latter is clearly not the optimal
way forward, and not what we want to achieve with ONAP, we should try to see
how we avoid it at least in a longer term, in my view. The former may be
significantly improved and timelines may be shortened, if we manage to work on
it effectively now and provide the shortest path to get there from the current
state - and Vimal's proposal of target merged architecture looks like a great
step towards it, preserving all functionality coming from APPC and VF-C, but
making a single set of external interfaces. I think we should give a very high
priority to those discussions and handle them now, in parallel to R1 work.
Best regards,
Alla Goldner
Open Network Division
Amdocs Technology
[cid:[email protected]]
From:
[email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Pasi Vaananen
Sent: Friday, July 21, 2017 11:15 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [onap-discuss] Architecture Progress
Hi Jamil,
In ONAP F2F in New Jersey, there was what I thought was "agreement" that there
is to be only one set of VNFDs / interfaces for ONAP. If that is strictly
enforced (like I think it should be, as these collectively form the "interface"
between the VNF vendors and ONAP - if the overlap would be e.g. on NS level
descriptors, it would not be as bad, as those could be considered to be system
internal and therefore not as much of inter-operability problem), then having
two parallel implementations means that they would need to do exactly the same
things, and be essentially "indistinguishable" from each other even on their
behaviors associated with these descriptors and interfaces.
Obviously, strict enforcement of this would imply about 100% overlap on the
associated development, testing, etc. activities (minus any sharing of code
between the teams). And, in addition, coordination between the two teams to
accomplish the required level of agreement in absence of the independent /
detailed specification that is to be implemented, which would further slow
things down.
If ONAP community chooses to allow divergence here for r1, it is going to be
hard to reverse later (assuming that someone would pick sides and actually
deploy the result - more likely outcome is that VNF vendors would want to wait
until the divergences are resolved, i.e. R2 at the earliest per current
"plan"). It is also going to be difficult to "push back" on e.g. ETSI and OASIS
on descriptors etc. if ONAP community itself cant get into one opinion on what
to push.
I like Vimal's "Target Merged Architecture" slide #3 at high level - what is
the shortest path to get there from the current state ?
Regards,
Pasi
On 07/21/2017 03:09 PM, [email protected]<mailto:[email protected]>
wrote:
Hi Chris
I have participated partially to the last 2 meetings, my position was
represented by Vimal. We need time to analyse the output before to take a
position and as you know the subcommittee is consultative and we need to
discuss the output in the TSC.
I think we have clearly Identified overlap between 2 approches and there is a
high risk to not have a useful Rel-1 as we have many changes on the technical
components in addition to 2 different VNF guidelines.
Regards
Jamil
Cordialement
Jamil
Le 21 juil. 2017 à 20:17, Christopher Donley (Chris)
<[email protected]<mailto:[email protected]>> a écrit :
Dear Jamil,
I'd like to invite you to participate in our ARC calls. We generally meet
Tuesdays from 1400-1600 UTC (but we'll have to adjust next week due to the
developer meeting). We have considered multiple presentations over the last
four weeks (including the one you referenced), and after careful discussion, we
aligned on the release 1 and release 2 functional architecture I shared. I
held consensus checks on each of the last two calls and did not hear dissenting
opinions from the high level approach. The version of the diagram that I shared
represents the community consensus from Tuesday's call. If you have concerns,
please share them during the meeting. I'll be happy to reserve a slot on the
agenda.
Chris
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]]
Sent: Friday, July 21, 2017 8:59 AM
To: Christopher Donley (Chris)
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
Subject: RE: Architecture Progress
Dear Chris
Thank you for your work and the presentation, we can say that this is a first
step but we have not agreed on the architecture mentioned in your slide as
Vimal presented another architecture (consigned by AT&T, Amdocs and Orange).
Regards
Jamil
De : [email protected]<mailto:[email protected]>
[mailto:[email protected]] De la part de Christopher Donley
(Chris)
Envoyé : jeudi 20 juillet 2017 22:05
À : [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Cc : [email protected]<mailto:[email protected]>
Objet : [onap-tsc] Architecture Progress
Dear ONAP Technical Community,
I'd like to update you on progress from the Architecture Committee.
* For Amsterdam, we agreed to use the current architecture, as discussed
since ONS. This is to reduce risk of late changes to the project teams, who
have built their plans based on the current baseline.
* Longer-term, starting with Release 2, we reached consensus on an
approach to resolve the APP-C/VF-C challenge. We are developing a three-layer
orchestrator/controller functional architecture, with service
orchestration/resource orchestration/controllers. Note that this functional
architecture does not imply a project structure. Between now and the beginning
of the R2 planning cycle, the team will drill down to the next level of detail
on interfaces and project alignment, and then the projects will map code into
the architecture to guide R2 plans. Cross-project discussions have already
begun, and will continue over the coming weeks. Meeting logistics will be sent
to the ONAP-discuss email list for those who are interested in participating.
I have attached a set of diagrams that we reviewed in the Architecture
Committee to illustrate both the R1 and R2 architecture. Note that in the R2
slide, since we are focused on the functional architecture and not the
projects, we removed some of the boxes listing projects that support ONAP, but
don't provide interfaces or data flows through the system.
For those interested in more detail, we will discuss this during the developer
meeting next week.
Chris
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
onap-discuss mailing list
[email protected]<mailto:[email protected]>
https://lists.onap.org/mailman/listinfo/onap-discuss
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
<https://www.amdocs.com/about/email-disclaimer>
_______________________________________________
ONAP-TSC mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-tsc
