wiki:tc_minutes_20150319
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
wiki:tc_minutes_20150319 [2015/03/19 21:55] Bin Hu |
wiki:tc_minutes_20150319 [2015/05/06 20:06] (current) Daniel Farrell Use new SFC URL |
||
|---|---|---|---|
| Line 52: | Line 52: | ||
| 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. | 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. | + | 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 | * Project Proposal Discussion - 30 minutes | ||
| * Discussion of Requirement project proposals | * Discussion of Requirement project proposals | ||
| * [[requirements_projects:multisite|Multisite Virtualized Infrastructure]] | * [[requirements_projects:multisite|Multisite Virtualized Infrastructure]] | ||
| + | |||
| + | 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 | ||
| + | |||
| * [[requirements_projects:escalator|Escalator]] | * [[requirements_projects:escalator|Escalator]] | ||
| + | |||
| + | 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 | * Discussion of Collaborative Development project proposals | ||
| * [[/compass4nfv|Compass OPNFV Provisioning]] | * [[/compass4nfv|Compass OPNFV Provisioning]] | ||
| Line 71: | Line 100: | ||
| Postponed | Postponed | ||
| - | * [[/network_function_chaining|Network Function Chaining]] | + | * [[/service_function_chaining|Service Function Chaining]] |
| Postponed | Postponed | ||
wiki/tc_minutes_20150319.1426802116.txt.gz · Last modified: 2015/03/19 21:55 by Bin Hu
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: Creative Commons Attribution 4.0 International License
