EUAG 2019-03-26 meeting minutes

Attendees: 

Community: @Beth Cohen @Ahmed El Sawaf @guochuyi @Herbert Damker @Ryan Hallahan @Saad Ullah Sheikh @David Perez Caparros @Guy Meador @Vincent Colas

LFN: @Former user (Deleted) @Jim Baker @Kenny Paul @Heather Kirksey

Survey results: Compliance and Verification Program Survey and OVP beta program

  •  @Heather Kirksey

  • Review the survey results

  • VNF implementation, compliance testing, NFVI /VIM compliance tope responses

    @Heather Kirksey need confirmation on the algorithms  - used surveymonkey stack ranking type]
    @Heather Kirksey  look into providing the information as a list.
  • 66% of responses said they were planning to use both HEAT and TOSCA templates

    • @Beth Cohen believes that within a company different BUs may be using different models based upon history

    • @Herbert Damker  feels "HEAT is the language of today" and TOSCA will be the language of the future. Openstack is in use and currently uses Heat.

    • Q: is ONAP in production anywhere? A: @Ryan Hallahan Yes, ONAP in production

ONS NA and CVC joint meeting - unconference

  • Intention use the feedback from the EUAG to feed into roadmaps and inputs to the technical communities

  • If EUAG members cannot attend, please consider sending a proxy

  • Targeting Weds afternoon for meetup at ONS

  • CANCELLED EUAG stand-alone unconference to focus attention on the CVC interactions

ONAP Use cases / functional requirements for the next release (R5, El Alto) @David Perez Caparros

Get feedback from the ONAP TSC leadership on how to best provide EUAG priorities for El Alto @Jim Baker

ONAP consumption process - Round Table

  • Internal test/verification

  • lifecycle of a single version

  • internal repackaging/customizing

  • @Ryan Hallahan response on ONAP deployment process

    • Not all of ONAP used in production (subset of components) - focused on E-COMP components (Heat based flow)

    • not running ONAP "straight out of the box"  but not really expected that anyone will

  • @Beth Cohen Wouldn't except any telcomm to run ONAP right "out of the box"

    • AT&T had a couple year head start as E-COMP was internally developed BEFORE ONAP

  • @Ryan HallahanFiguring out how to consume the new contributions from the community is the challenge.

    • Have a team merging and testing new contributions.

    • Have some AT&T specific contributions that are kept internal - 2 way merge

    • There a couple of projects that are only AT&T contributions that are easy to consume, and others that are very diverse that need to be merged into AT&T base on a ~weekly schedule

    • Cloning and merges can be automated but merge conflicts need to be addressed by hand obviously

    • want as much in the community as possible, but there are AT&T cloud specific that needs to be internally addressed

    • Some refactoring and automation can help, don't think that human merges are avoidable.

  • @Beth Cohen Because Verizon is always "pulling" ONAP, the 2-way merge is not as much as an issue

  • @Former user (Deleted) Expect some operators to consume ONAP directly from a vendor (turnkey) - expect to see the full spectrum of make/buy

  • @Ryan Hallahan Yes, pull/2-way merge is a legacy of how ONAP evolved AND internal cloud uniqueness

    • Tailor ONAP to the environment?

  • @Heather Kirksey What percentage of ONAP would be specific to your environment? What would be you goal? Realistic ideal?

  • @Beth Cohen always eval build vs. buy - if ~70% is buy then it makes sense and then work on customization

Chat log

08:30:16 From David Perez (Swisscom) : https://wiki.onap.org/display/DW/Release+5+%28El+Alto+%29proposed+use+cases+and+functional+requirements
08:30:23 From David Perez (Swisscom) : https://wiki.onap.org/display/DW/SP+priorities+for+Dublin
08:37:04 From Kenny Paul (LFN) : https://wiki.onap.org/display/DW/SP+priorities+for+Dublin
08:47:20 From Herbert Damker (DT) to Jim Baker (LFN) (Privately) : in my statement above it should be "future" instead of "feature"