Minutes of Technical Community Discussion on March 19, 2015
Date and Time: UTC 13:00, Thursday March 19, 2015Convenor: Bin Hu (AT&T)Participants:- Al Morton (AT&T)
- Avinash S (Huawei)
- Bryan Sullivan (AT&T)
- Charlie Hale (IBM)
- Chaudhry Usama
- Christoph Meyer (Ericsson)
- Dave Neary (Redhat)
- Dick Chen (ZTE)
- Frank Zdarsky (Redhat)
- Gerald Kunzmann (DoCoMo)
- Howard Huang (Huawei)
- Iben Rodriguez (Spirent)
- Jie Hu (ZTE)
- Joe Huang (Huawei)
- John McNamara (Intel)
- John Messenger
- Julien Zhang (ZTE)
- Manuel Rebellon (Sandvine)
- Marc Szczesniak (Casa)
- Maria Toeroe (Ericsson)
- Maryam Tahhan (Intel)
- Mike Young (Huawei)
- Narinder Gupta (Canonical)
- Nauman Ahad
- Prakash Ramchandran (Huawei)
- Praveen Kumar
- Raymond Nugent (Huawei)
- Ruan He (Orange)
- Ryota Mibu (NEC)
- Steve Gordon (Redhat)
- Stuart Mackie (Juniper)
- Tomi Juvonen (Nokia)
- Trevor Cooper (Intel)
- Ulrich Kleber (Huawei)
- Wei Su
- Xinyu (Jerry) Zhao (Huawei)
- Yuri Yuan (ZTE)
- IRC Log available
- Draft Blueprints Discussion - 30 minutes
- Event Publisher for Alarm from Doctor project
- Notification-driven Alarm Evaluator from Doctor project
Ryota from NEC presented Ceilometer BP drafts from Doctor project. He primarily introduced fault management scenario, implementation plan in OpenStack, Ceilometer architecture, and how Event Publisher for Alarm and Notification-driven Alarm Evaluator will fill in the gaps in Ceilometer.
The questions focused on technical approach in messaging system. Bryan (AT&T) asked what is the concept of listening, waiting for a response, or subscribed to a channel? Ryota clarified that it meant the subscription to AMQP/RabbitMQ message queue. Bryan indicated that the message queue will not be only internal to OpenStack, and that the technology choice is important for scalability. Ryota clarified that in this context, he is talking about Ceilometer listening internally for events, not external clients consuming events from the OpenStack platform. Bryan emphasized that choice of technology for "listener" is important as this will affect the scalability. we have to consider a variety of dimensions in a generic event notification system for use inside openstack as well as to outside event consumers - TPS is just one, e.g. # of connections, variety of subscribed events, overload protection, etc.
Dave Neary (Redhat) asked how Ryota plans to co-operate with ETSI NFV, and when we can see an updated draft of the blueprint. Ryota confirmed that once the plan is agreed in OPNFV, he would update the blueprint in OpenStack with more details. The purpose here is to seek consensus of this plan.
Bryan indicated that for the Copper blueprints, he would be diving into these aspects under the specs repository per the rough blueprints on the wiki, using the openstack template. Bryan suggested that we ensure that the common goals of doctor and copper re event notification are aligned before we go to OpenStack.
Frank (RedHat) asked what the scaling and timeliness goals are for the solution. Ryota responded less than 1s for reacting to server issue.
It appeared that more collaboration and review is needed before submitting a blueprint or updating current blueprint with more details to Ceilometer because of overlapping goals with Copper etc.
Dave Neary (RedHat) emphasized that although we can go to OpenStack discussions and the summit with diverse proposals, it would not be optimal for common aspects at least. We should have the blueprints in git and review each other's that way before we get too far.
- Project Proposal Discussion - 30 minutes
- Discussion of Requirement project proposals
Joe (Huawei) introduced the update of the proposal, and keystone failover mechanism.
Gerald (DoCoMo) indicated that the text below the figure is confusing. The listed projects currently are not investigating the multi-site aspects but are focusing on the requirements for single-site deployments. So text should be revised. Howard (Huawei) agreed that it needs more feedback from the projects that would have multisite requirement.
Bin (AT&T) asked about the specific deliverables of the project. Howard agreed that the deliverables need to be updated with more specific information.
Gerald (DoCoMo) asked what is the plan of how to work together with the related projects, which working process will be followed. For example, should people from different projects join the multisite weekly meetings, or vice versa? Howard said that the plan is to trigger joint meetings by BP proposals.
Gerald (DoCoMo) also indicated that the proposal looks like an integration project. Bryan (AT&T) indicated that we need some method of creating a common area where issues that affect multiple projects can be surfaced and tracked. This may be more than a tooling issue, but perhaps we could use tags of some sort on issues.
Iben (Spirent) proposed that multisite project may work on high level requirement that can be applied to other projects, which will trigger the other projects for specific topics relevant to multi-site, but currently not yet addressed by the individual projects. The list of sub-projects may be created for tracking the compliance with multisite requirement.
It appeared that the proposal needs further revision, e.g.:
- Text below the diagram
- Deliverables
- Scope, i.e. top-down high level requirement that can be applied to and guide individual projects, trigger the compliance review and compliance tracking
Jie (ZTE) briefly introduced this project for 3 minutes. Due to time constraint, meeting finished and all agreed to continue the discussion in mailing list and at the meeting next week.
- Discussion of Collaborative Development project proposals
Postponed
Postponed
Postponed
Postponed
- Discussion of Integration and Testing project proposals:
None
- Discussion of Documentation project proposals
None
- Discussion of other projects
None
Note: Testbed, SR and CI have their own conference calls to discuss relevant details.
Meeting adjourned
