I would say something like: “ It offers a set of MS which provide reusable optimization functionality which can optionally be used by other ECOMP components if required by a use case.”
I like MS better then SDK but I think we agree. Can certainly change to may. Thx Oliver > On Jun 22, 2017, at 3:35 PM EDT, Christopher Donley (Chris) > <christopher.don...@huawei.com> wrote: > > Oliver, > > Just to clarify the governance question: is this project producing a set of > services or an SDK that other projects can choose to implement or is it > producing artifacts that they must implement? > > From your example, I read it as the former (that projects can choose whether > or not to utilize oof), rather than a mandate. If so, I’d recommend updating > the proposal (particularly the architecture alignment section) to change > “[may|will] need to….” language to “may ….” to clarify that point. > > Also (since it will come up tomorrow), please adjust the committer list. > Everyone on the project is currently listed as a committer. > > Chris > > From: onap-tsc-boun...@lists.onap.org > [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of SPATSCHECK, OLIVER > (OLIVER) > Sent: Thursday, June 22, 2017 10:31 AM > To: Stephen Terrill > Cc: PUTHENPURA, SARAT (SARAT); onap-tsc > Subject: Re: [onap-tsc] Optimization framework > > > I think there are a couple of misconceptions here. > > This is not the change management project. The change management project was > about the end to end use case flow needed to perform change management. This > project ONLY provides the schedule optimization part of that flow. The flow > itself touches many projects and as discussed I agree is best handled as a > use case. The actual flows would be implemented using all the regular > components which at one point in the flow call out to this project for an > optimization decision. > > The same is true for homing. > > So let me try to illustrate the flow of this a bit better. The scope of the > project is algorithms and a run time framework to : > > 1. gather and normalize data to perform an optimization decision based on a > request > 2. gather the polices from the policy engine provided by the policy project > using standard APIs exported by that project > 3. formulate the optimization problem > 4. run the optimization algorithm (this might be iterative with the prior > steps) > 5. return an optimization result to the requestor > > So let me give a homing related example. > > Let’s assume a workflow in the SO is triggered to instantiate a VNF. As part > of the workflow there might be a call into HAS to derive the optimal > location. The constrains for the placement are associated with the policy > (handled in the policy project) for that VNF. HAS will now go to A&AI and > DCAE (using the regular A&AI and DCAE APIs) to gather enough data to make a > placement decision at which point HAS would return the result back to the SO > so the SO can proceed instantiating the VNF following the rules in it’s > workflow. > > Please note that the call out to HAS was part of the SO workflow for that > particular VNF. It’s under the control of whoever designs the SO workflow > (likely the specific use case) if HAS gets called or not and what constraints > are communicated. > > In terms of execution of all of this. Parts currently run as independent MS > other parts run as MS managed on DCAE. Again this project just uses > infrastructure that already exists. > > You also mentioned CLAMP. CLAMP flows as any other flow in ONAP could call > out to the optimization framework if it helps. If it doesn’t the flows don’t. > > So this should explain how this project does not “hurt” any other project and > is aligned with the architecture. > > Now if I interpret your second question correctly you are also asking “How > does it help?” . > > The reason we want to combine all of this in one project is that there is > reusability in the code required in steps 1.-5. > > For example: > > 1. + 2. requires code to gather information from many existing ONAP > components and present them in a common format so they can be used to derive > the optimization formulation. > > 3. + 4. as we do not believe that there is one formulation/optimizer which > solvers every problem we do believe that the same formulation approach > combined with a set of optimizers and constraints can cover a large set of > diverse use cases leading to reuse in this area too. > > So the benefit of the project as the library of > formulations/optimizers/runtime framework grows will be that instead of > writing code for new optimization challenges they can be just configured or > at least will require minimal code development. > > Does that address your concerns? > > Please advice how you want to document this? E.g. I can add this as a comment > to the project proposal. I think the proposal already makes above points but > I am probably biased as I have read it too many times …. . > > Anybody else? > > I am wondering what it would take to put this on the schedule tomorrow so we > can close on those things? > > Thx > > Oliver > > > On Jun 22, 2017, at 12:38 PM, Stephen Terrill <stephen.terr...@ericsson.com> > wrote: > > Hi, > > I had an action to start a thread about the optimization framework : > https://wiki.onap.org/pages/viewpage.action?pageId=3247288 > > To start with, my question is not on the need of optimization and Change > management, nor about release vs project (that can be sorted out) but about > the architecture and related project structure we should have for this > functionality. Basically I am wondering concretely what this is and how > best it should be done. > > For optimization: > The way HAS is described it sometimes appears as an extra module that > receives information from DCAI, AAI, makes a resource allocation decision and > stores that in A&AI. This interpretation of the approach leaves me wondering > about the overlap with: > • DCAE applications (if I can use the word) > • Policy framework > • Orchestration and controllers (which should update A&AI). > • CLAMP from a SDC perspective? > Another interpretation is that HAS is something that is called from DCAE, > CLAMP, SO, Controllers, and appears to be that there is commonality between > them hence worth having as a common module. Is it really common? Instead > isn’t it addition on CLAMP, new DCAE applications, SO and controller modules? > If so, should we go ahead and place the work in those projects? > > For CMSO: > • I understand this replaces the change management project? > • I understand from this description that it is a separate, new module > that is created. > > BR, > > Steve > > > > > > > STEPHEN TERRILL > Technology Specialist > DUIC, Systems and Technology > Development Unit IP & Cloud > Business Unit, IT & Cloud Products > > Ericsson > Ericsson R&D Center, via de los Poblados 13 > 28033, Madrid, Spain > Phone +34 339 3005 > Mobile +34 609 168 515 > stephen.terr...@ericsson.com > www.ericsson.com > > > > > Legal entity: Ericsson España S.A, compay registration number ESA288568603. > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer > > _______________________________________________ > ONAP-TSC mailing list > ONAP-TSC@lists.onap.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4&m=dNr5ltWWA7SKaG4NqMZV-dzrpEzUKcM1olD3XBG_hA4&s=E8gmzINMlvN7cQFt_3W8y3hTpVRbyxCC6XQeU0_8ZNw&e= _______________________________________________ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
