Skip to end of banner
Go to start of banner

EUAG 2019-04-09 meeting minutes

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Attendees: 

Community: Atul Purohit Saad Ullah Sheikh David Perez CaparrosguochuyiRyan Hallahan

Beth Cohen Ahmed El Sawaf  Herbert Damker Guy Meador Vincent Colas

LFN: David McBride Jim Baker

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"


  • No labels