High Level

The POMBA code and containers are an implementation of a model based audit where logging transaction tracing would assist this new audit code in determining the differences and causes of any discrepancy between the model intent and the reality of VNF orchestrations.

Actions

A new set of new microservices around orchestration model based auditing are being proposed as an addition to the logging project and up sourced into ONAP for the Casablanca release.

A meeting with the architecture subcommittee is planned for the 29th of May.https://lists.onap.org/pipermail/onap-discuss/2018-May/009660.html

Jon Taylor and Geora Barsky (assisting) and Sharon Chisholm (assisting) will presenting the proposed architecture along with myself.

Team members

In addition to the current logging team members

Neal Chatterley

Luke Parker

Lee Breslau

Dave Williamson

Shane Daniel

Shishir Thakore

Sanjay

Avdhut Kholkar

Ray Chang

J. Ram Balasubramanian

Michael O'Brien


The following additional team members - the majority of which currently work/have-worked on SDNC like the clustering and federation work in ONAP will also support the scope change work.

Sharon Chisholm

James MacNider

Geora Barsky (sniro)

Jon Taylor

Jennie Jia

Brad Benesch

David Stangl

Mohammadreza Pasandideh

Prudence Au

Trevor Tait

Phillip Leigh

Vitaly Lavrusevich

Pierre Rioux

Stela Stoykova


With additional ongoing support/work from the OOM project

Mike Elliott

Roger Maitland

Mandeep Khinda

Borislav Glozman

Jerome Doucerain

Plan

Cover off all the items identified in the scope change epic, including overlap with other projects, what we require from other projects and what other projects may require from us in terms of API.

LOG-192 - Getting issue details... STATUS

The POMBA microservices will require their own sub repo - ideally per/container as a sub-project of logging.  See https://gerrit.onap.org/r/#/admin/projects/logging-analytics,branches - raising LF ticket





  • No labels

6 Comments

  1. Michael O'Brien

    also posted to the wiki
    https://wiki.onap.org/display/DW/Architecture+Subcommittee
    https://lists.onap.org/pipermail/onap-discuss/2018-May/009659.html

    Chris,
    Can we delay the scope change meeting for logging until next week – the 22nd.
    I understand the Architecture team is at a conference next week – so likely we will do this scope change on the 29th in 2 weeks.
    Can I request the first hour – as we have our logging meeting in the 2nd hour of the Arch meeting
    Thank you
    /michael

    From: onap-tsc-bounces@lists.onap.org [mailto:onap-tsc-bounces@lists.onap.org] On Behalf Of Michael O'Brien
    Sent: Friday, May 11, 2018 9:41 AM
    To: Christopher Donley (Chris) <Christopher.Donley@huawei.com>; onap-discuss@lists.onap.org; onap-tsc <onap-tsc@lists.onap.org>
    Subject: [onap-tsc] [ARCH] Request scope change review: POMBA introduction in Logging project for Casablanca

    Chris,
    Hi, the logging project would like to introduce a proposed scope change for Casablanca – we would like to pass these adjustments by the architecture subcommittee and the community before meeting the use case subcommittee.

    https://wiki.onap.org/display/DW/POMBA
    The expanded clickable team member list is on the sub page
    https://wiki.onap.org/display/DW/Logging+Scope+Change+for+POMBA+seed+code#LoggingScopeChangeforPOMBAseedcode-Teammembers

    I would expect 15 min.
    1) Jon Fannar Karlsson Taylor and Sharon Chisholm will be presenting
    2) Heads up review of the architecture proposal, the new microservices, new API capabilities provided by the audit, any overlap with other projects, requirements on other projects and use case discussion


    This meeting is separate from the ongoing review of the Logging specification and implementation under the following that we discussed at last week’s Architecture meeting
    https://jira.onap.org/browse/ONAPARC-148

    Let us know if there are any additional requirements.
    Thank you
    /michael


  2. Michael O'Brien

    Notes for Tue meet with Arch SC

    • Formal approval process?
      • Any LF work
      • TSC presentation after ARC presentation
    • Presentation
      • As new project or sub-project - (sub-project) -
      • logging complements pomba/audit
    • Major use case
      • Design intent model matches what was deployed
      • data integrity
      • generating reports
    • Implementation
      • REST based, no special S3P requirements, 

    • Interfaces
      • Northbound: Kibana only
      • Southbound: - SDNC covers off SDNC (Openstack) now, MultiVIM in Casablance (Azure + Openstack)
    • impact on teams
      • work required if a team uses POMBA capability (optional):
        • SO
      • work required for POMBA to work: 
        • SDNC - already started in ONAP
    • list of services (Michael O'Brien)
    • Overlap between existing projects (Michael O'Brien,)
      • SDNC: Tech Mahindra's Epic -  SDNC-231 - Getting issue details... STATUS
    • Parent Project Discussion? (Jon)
      • Logging is already a platform project where most of the team already works, we can move in the future if required.


  3. Michael O'Brien

    20180529: Arch review notes - Jon Taylor presenting - Duration: 55 min - 43 participants

    • Q) Gil Bullard - att 
      • looking for bugs
      • redoing composition? - expected to produce?
    • A) 
      • audit could indicate a bug in composition, but more about anomaly detection (4 instead of 5 VMs instantiated for example - for a static config)
      • matching desired intent to actual
    • Q) Chaker
      • Overlap with AAI, will pomba inspect openstack?
      • Initially resource level audit - memory, cpu etc- later multivim level attributes
    • Q) Ramki - expanding on VIM level attributes - tenant etc...
    • A) Sharon Chisholm - detailing what the plan for VIM level auditing 
    • Q) Alexander Vul - Only openstack
    • A) Sharon/jon/mike - will support multivim for C - not specific to openstack -for example the Azure work in multivim
    • Q) Alex - operational policies (optimimum 4, but minimum 3) - scaling policies - support?
    • A) rules coming from SDC - we can adjust for operational rules coming in
    • Q) logging tool
    • A) Platform tool/ assurance tool
    • Q) Stephen Terrill - should be in orchestration instead of logging?
    • A) Yoav Kluger - Audits operation of ONAP - we could put it anywhere but 
    • Q) Gil B - how do we know that the audit is correct - and could we just do this via SDC query?
    • Q) Alex V. orchestration via drift management
    • Q) Ranny Haiby: how do we get to 
    • A) Sharon/Yoav: if POMBA is called immediately after orchestration - better, but we can do random audits of existing services (diff since orchestration)
    • Q) Checker: do we need to reinstantiate the templates to determine for sure the state
    • A) Yoav: for now just discrepancy differences
    • Q) Alex V. - validation (image, config...)
    • A) Jon - vf validation is on the plan
    • Q) Manoj Nair: automated active testing - emulate a client for the service, initiate traffic flow...
    • A) Yoav/Jon/Sharon - no way to verify all the service resources are being covered - redundant path wont be known until a failover for example
    • Q) how to work with the project
    • A) A context builder is required per component
    • Q) detail exactly how the context builder works with for example SDC - what is the kibana output
    • Q) Chris, new project or part of logging
    • Q) Chaker: Recipe timing is critical - order of operations 
    • A) need examples of where order would be problematic - beyond readiness healtcheck for example

    From zoom


    From Me to Everyone: 10:04 AM
    https://wiki.onap.org/display/DW/POMBA original Arch Review request - onap-discuss -fyi https://lists.onap.org/pipermail/onap-discuss/2018-May/009660.html
    From Me to Everyone: 10:21 AM
    We will need to align with Multivim work in C* for example the Azure work in progress - as an undercloud abstraction
    From Sharon Chisholm (Amdocs) to Everyone: 10:22 AM
    It may not be ready.
    From Stephen Terrill to Everyone: 10:32 AM
    It seems like the assurance scoped to the could infra. Buidling assurance ontop of ONAP, won't it have to do the same things again?
    From Sharon Chisholm (Amdocs) to Everyone: 10:33 AM
    Assurance should be based on the state of services, QoS metrics, etc. That isn't what POMBA is necessarily doing.
    From Ranny Haiby to Everyone: 10:34 AM
    Agree with @Stephen Terrill - POMBA seem to have a role as part of ONAP assurance
    From Stephen Terrill to Everyone: 10:35 AM
    not necessarily agreeing there; that is correct for the application level scope. HOwever for the cloud level scope it seems to overlapp.
    From Sharon Chisholm (Amdocs) to Everyone: 10:37 AM
    Whether it is labelled as part of Logging or part of assurance probably matters less than the fact that the problem being solved is important.
    From Stephen Terrill to Everyone: 10:39 AM
    Right - the point I was trying to get to is the functional allocation of this functionality in the architecture.
    From Chris Donley to Everyone: 10:39 AM
    To me, it feels like this should be a separate project, with ties into logging, DCAE, and possibly others.
    From Stephen Terrill to Everyone: 10:41 AM
    Or it looks like a use case with parts in DCAE, SO, Logging, ...
    From Yoav Kluger (Amdocs) to Everyone: 10:41 AM
    definitely an option Chris. We were wary of he vast number of projects in ONAP ..
    From Chris Donley to Everyone: 10:44 AM
    Yoav, I think it will make the project and scope management easier to have this separated out. We're actually pretty small in the number of projects compared to ODL, OPNFV, etc. We have some room, if it's warranted.
    From Yoav Kluger (Amdocs) to Everyone: 10:44 AM
    OK, this is good input
    From Stephen Terrill to Everyone: 10:45 AM
    I think that would be promiting a vertical stack to point provide this capability in stead of building it into the architecture
    From Chris Donley to Everyone: 10:47 AM
    There probably needs to be an entity (with a CLI, etc.) to kick off this process, and then potentially other pieces in related projects. From the presentation, I don't see it fully contained in existing projects.
    From Stephen Terrill to Everyone: 10:51 AM
    Presenting the service state?
    From PARVIZ Yegani to Everyone: 10:51 AM
    https://docs.aws.amazon.com/aws-technical-content/latest/microservices-on-aws/auditing.html

    From Me to Everyone: 10:53 AM
    notes here and auditory on the note at the end of https://wiki.onap.org/display/DW/Logging+Scope+Change+for+POMBA+seed+code?focusedCommentId=33067952&refresh=1527605584829#comment-33067952 thank you very much team for the discussion
    From Kevin McDonnell (Huawei) to Everyone: 10:54 AM
    Good link...my take is POMBA is not trying to be a Cloudtrail or CloudWatch...but something less ambitious... I think its firstly a diagnostic tool..
    From Me to Everyone: 10:54 AM
    Parvis I am all in on AWS - reviewing link
    From Kevin McDonnell (Huawei) to Everyone: 10:54 AM
    in order of increasing ambition. Diagnostic, Audit, Discovery, Audit_Compliance+Verification and finally Assurance...
    From PARVIZ Yegani to Everyone: 10:55 AM
    Tnx Michael.


  4. Michael O'Brien

    20180612: arch meet - Sharon Chisholm presenting

    From Raghu Ranganathan to Everyone: 10:28 AM
    sharon - is the primary reason to get context from multiple entities due to different models?


    Stephen, (PTL)

    Place POMBA in logging project - approved

    Scope change document must be passed by the TSC

    Need impact statement for each ONAP component - phased (short term context builders in logging  project - over time moved out to other projects

    Stephen

    The analysis part may need to be part of the dcae project in the future


    TSC vote tomorrow

    https://lists.onap.org/pipermail/onap-discuss/2018-June/010323.html

    TSC 2018-06-14

  5. Michael O'Brien

    Approved at 0510 on 20180621 in Beijing GMT+8

     TSC 2018-06-21 (Beijing)

  6. Michael O'Brien

    Team, Gildas, we discussed the zip issue some more - (zip files not allowed in git), we decided that since SDC works with tosca zip files then to fully test our interaction with SDC we need to be able to have zip files available to the testing framework - changing this review off -1 for zip submission Note: we should document this decision for the future when an audit of the code is done - I will send a mail to onap-discuss but it would be good if the javadoc of the testcase explained this zip requirement so we can link to git from the review, jira and release review

    LOG-522 - Getting issue details... STATUS

    https://gerrit.onap.org/r/#/c/57083/3/src/test/resources/toscaModel.csar.zip,unified