Attendees:
Please add your name in here:
- Kelvin Edmison (Nokia)
- Mark Shostak
- Tomas Fredberg (Ericsson)
- Pankaj Goyal (AT&T)
- shasha guo (ChinaMobile)
- Gergely Csatari (Nokia)
Special Notes:
- Given the limited time available, we will focus on identifying issues/actions/next steps, but not solving them right now
- Weekly RM meetings are intended to
- Identify owners for new Issues
- Track open Issues
- Address technical issues that cannot be resolved online (i.e. resolve stalls)
Agenda:
- Discuss RM Specific sessions we want to have in Los Angeles - ONES LA Topics Proposals - Technical
- Proposals/ideas due by end of week:
- RM Deep Dive
- consider topics that are 'below' the line' for Baldy, but need kickstarting for the next release
- Others
- Proposals/ideas due by end of week:
- Generic Fabric Model (GFM)
- [RM] Networking Strategy (Issue #960)
- The following is proposed for Baldy MVP
- Executive Summary
- CNTT approach to the fabric // i.e. define for flexibility in ultimate implementation
- Initial Objectives // i.e. what we want the GFM to achieve for CNTT (and why) Ex.:
- Provide L3 tenant networks, GWs, SDS, etc.
- CLEANLY decouple interface/reference points between CNTT constituencies
- Provide compatibility at demarcation/reference points
- any RA couples to RM
- appropriate RI couples to RA
- Operator can create or procure a compatible fabric, etc.
- Provide ability for any number of Operator-specific fabrics to power an RA/RI/VI
- Enables RC's ability to realize their deliverables
- Clearly documents responsibilities of each CNTT constituency
- Your ideas here!
- Provide enough mechanics for contributors to create coherent requirements
- What are the buckets // Tech, RM, RAx, RIx, etc.
- Examples of what goes in each bucket // Exec Summary & approach (Tech); generic/high-level requirements (RM), detailed requirements (RA), Sample imp to support RC (RI), etc.
- Your ideas here!
- Executive Summary
- Open questions
- TBD
- New Business
Actions:
- General
- Document decision (flowing from #1007) about choosing Flavours over scheduler_hints
- based on discoverability, absence of traceability from scheduler_hints option, and based on openstack recommendation link
- Note in RM that compute flavour is parked, but don't remove it from the Reference Model entirely as we are re-adding it soon.
- Document decision (flowing from #1007) about choosing Flavours over scheduler_hints
- Core
- None at this time
- Ops
- None at this time
- Comp
- None at this time