Welcome to the ONAP Optimization Framework (OOF) Project. We are gearing up for development sprints for the first release of OOF. As part of this process, here is a request for the project members to please review the following material, and provide feedback and comments. Your input will be valuable in ensuring that the project starts of off with all of us have our goals aligned as best as we can, and help realize this project as a joint, collaborative effort.

Here are the resources for which your input and feedback will be valuable:

  1. Time Critical:OOF Beijing Release Planning Page (https://wiki.onap.org/display/DW/OOF+Beijing+Release+Planning).
    This page has information on what we are trying to accomplish as part of this release (next couple of months of design and development followed by integration, testing, etc.) Please review this document and provide feedback.
    1. This is a work in progress and all input is welcome. Most notably: (a) identification of new user stories and tasks within those, (b) volunteering to taking a crack at some of the user stories and tasks, (c) suggestions on improving the readability of the document, and (d) filling in tasks and user stories that are critical to meeting the deliverables. Everything from scenarios, test cases, code commits, offers to do code reviews, etc., is more than welcome.
    2. There are a few user stories that need to be created. Likewise, we need to fill in details in a couple of places (details on project dependencies for starters).
  2. Documentation of OOF
    1. The main documentation homepage for OOF (https://wiki.onap.org/display/DW/ONAP+Optimization+Framework). This page tries to cover the big picture (motivation, rationale, technology, examples, etc.)
    2. ONAP-OF Project Proposal (https://wiki.onap.org/pages/viewpage.action?pageId=3247288). This is a bit dated document – an original proposal from over six months ago that tries to capture in general terms what we started off with as the goals. The main documentation homepage vastly builds on top of this.
    3. Homing and Allocation Service (HAS) page (https://wiki.onap.org/pages/viewpage.action?pageId=16005528). This page focuses on the HAS documentation and contains sub-pages on HAS specification guide along with policy and information sources.
    4. ONAP-OF Drafted Resources (https://wiki.onap.org/display/DW/ONAP-OF+Drafted+Resources+for+Discussion). This page contains some presentations from project meetings. It may be worth for extracting the gist of that information and adding in a wiki-editable format.

Please provide comments on this wiki page  if possible. A large number of comments on the main page may clutter the page, so please use the following page for now: https://wiki.onap.org/display/DW/Placeholder+for+general+comments+on+OOF+and+Beijing+Release. The idea is to have an active and engaging discussion in a transparent setting while keeping main content and discussion details separate. Please suggest other ideas or mechanisms if you think of better ways to do this.

Thank you all again for your engagement with the OOF Project. Here is to the hope that this proves to be just the start of a nice, meaningful journey.

  • No labels

2 Comments

  1. Manoj Nair

    Following are some of the comments (referring to page here)

    • I believe there may be a need for integration with MSB primarily to support API calls between SO and OSDF , OSDF and Policy.  I am not sure if this is expected to be done through the DMaaP. As I understand MSB is migrating to a Service Mesh based architecture, which require a sidecar to be supported in each component/MS/Docker container.  So the provision for sidecar might also need to be considered.
    • Referring to this sequence diagram, I believe the call from OOF-OSDF to OOF-HAS (Send Homing Request to Homing Service from OSDF to HAS)  is depicted as a synchronous call (OSDF waits till HAS returns).  I believe this will be a time consuming operation and there might be a need to make the call asynchronous – i.e OSDF returns immediately with a  request ID to SO and SO can keep polling OSDF to update the status.  But this will have implication on reliability/availability/state mngmt  as the OSDF might have to re-run the pending requests from backup in-case of a failure. I guess this capability of persisting the ongoing requests and state is planned to be leveraged from Music.
    • If I am not wrong the dependency diagram and the Sequence diagram are not in sync  . As per the dependency diagram SO is interfacing with HAS whereas the sequence diagram shows SO interface with OSDF. Probably OSDF and HAS are planned to be accommodated in the same container, but I believe it will limit the ability for OSDF and HAS to scale independently, develop independently. Can these two components reside in separate Microservices/Docker containers
    • Regarding OPTFRA-27, it will be helpful to elaborate what the TOSCA model mentioned here. This means the retrieved policy from Policy component is in TOSCA YAML format ? If this is the case there might also be a dependency on SDC TOSCA Parser to parse the TOSCA model.  Also what data is retrieved from SDC – Catalogue? VNF descriptors or Artifacts like license model ? Is OOF expected to listen for updates to the catalogue items and act upon that (for example change management, scale out might trigger a change in model parameters such as license association) ?

    1. Sastry Isukapalli

      Thanks Manoj for covering a significant area of the project.

      We should probably expand these into separate sections elsewhere when there is critical mass and then do the work on a wiki page. We should also get comments from others on these points.

      Quick responses here:

      1. Need for integration with MSB: Fully agree, (Q1) do we aim for this release or set as a stretch goal?
        1. For now, we are expecting a simple API call (a POST request)
        2. Yes, we should definitely consider MSB
        3. It would make sense to do this in a service mesh framework with proxies and sidecars
      2. The HAS sequence diagram should be updated (we should make it a gliffy diagram so that we can collaboratively edit it) 
        1. The original SNIRO flow was as follows: SO calls OSDF (SNIRO-Manager in ECOMP) with a call-back URL. OSDF calls HAS and keeps polling regularly and eventually sends a response to the call-back URL. 
        2. Implications for re-running pending requests are present. When we used a DCAE-CDAP like system, we implemented a "queue" where different workers will get "tasks" (wiith features like worker-timeouts). In the docker version all that functionality didn't get in. The queue has a very small footprint (just the request info, status, and what a hash for the worker it is assigned to), and has functionality of things like create, assign-worker, tag-orphan, tag-completed.  
        3.  Re-runnig the pending requests from backup in-case of a failure:
          1. We used HBase strong consistency for the queue in ECOMP
          2. We can use whatever option makes sense with Music, or some OOM storage option (etcd)
          3. We can ask SO to do a retry if there is no response within a specified period of time
      3. The sequence diagrams are not sync'ed. 
        1. Sync'ing up the sequence diagram
          1. Yes, they are not sync'ed, and we need to align such diagrams across the OOF (and get an OK with related projects)
          2. (Q2) Should we update the sequence diagram (I strongly recommend a wiki-editable format like gliffy)?
          3. Shankar/Matti, if you have the source file, we can use it. We can also recreate it from the image (Note: there is some chance that errors will be introduced when retyping the text from image)
        2. Whether the OSDF and HAS should be separate containers:
          1. That was how the ECOMP/SNIRO version was (manager and HAS were separate applications and had the running separately)
          2. However, having them in the same container might speed up things and be resource effective if we end up with a large number of applications (if we have "generic workers" that can do HAS, CMSO, or other optimizations, the resources can be pooled instead of reserving them for specific services)
          3. (Q3) Should we discuss the options in the next OOF call? (phrasing it as a question instead of a task)
      4. Regarding OPTFRA-27 and TOSCA models: 
        1. the phrase "TOSCA model" for policy refers to the TOSCA YAML format (please check the update there and see if changes are needed – please edit or add comments there)
        2. We may use the TOSCA parser or a simple YAML parser for this version – with target of moving to TOSCA parser later (stretch goal of Beijing Release, and definitely for Casablanca Release).
        3. While we haven't fully ironed out what all will be retrieved from SDC, the initial items we support are: (a) Policy YAML models, VNF descriptors, and license artifacts.
        4. OOF is not expected to listen to updates. We expect some process to update the models in this release. This needs to be improved upon in next release.