13:07:32 #startmeeting Technical review meeting - projects and blueprints 13:07:32 Meeting started Thu Mar 19 13:07:32 2015 UTC. The chair is dneary. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:07:32 Useful Commands: #action #agreed #help #info #idea #link #topic. 13:07:32 The meeting name has been set to 'technical_review_meeting___projects_and_blueprints' 13:07:57 #chair sgordon 13:07:57 Current chairs: dneary sgordon 13:08:43 #topic Blueprint review: Doctor 13:08:45 #info Bryan Sullivan 13:08:54 #info Steve Gordon 13:08:56 #link https://etherpad.opnfv.org/p/doctor_bps 13:09:16 I kind of skipped the attendance piece :-} 13:10:00 #info can someone drop a link to the docs for the notification bus feature of openstack? 13:10:19 I was about to ask the same thing - I have it on my phone, not desktop 13:11:08 #link https://wiki.opnfv.org/_media/doctor/opnfv_ceilometer_bp_from_doctor.20150319.pptx 13:11:51 #info John Messenger 13:12:09 #link https://wiki.openstack.org/wiki/Oslo/Messaging 13:12:10 #info Ryota Mibu presents the current plan for Doctor based on the slide deck above 13:12:32 bryan_att, Do you know which slide we are on? 13:12:36 #info I believe Oslo is what is being referred to 13:12:47 Slide 5/7 13:12:53 Thanks 13:13:00 slides are not numbered - this is "Ceilometer Arch" 13:13:17 Yes, slide 5 13:17:27 #link http://docs.openstack.org/developer/ceilometer/architecture.html 13:18:18 #info bryan_att asks: what is the concept of listening? Waiting for a response, or subscribed to a channel? A: Subscribed to AMQP/RabbitMQ message queue 13:20:03 AMQP is a protocol 13:20:07 not an implementation 13:21:51 #info bryan_att contends that the message queue will not be only internal to OpenStack, and that the technology choice is important for scalability. Ryota clarifies that in this context, he is talking about Ceilometer listening internally for events, not external clients consuming events from the OpenStack platform 13:22:27 #link https://wiki.openstack.org/wiki/Oslo/Messaging#Transport_Driver_API 13:23:51 #link https://wiki.opnfv.org/_media/doctor/opnfv_ceilometer_bps_from_doctor.20150319.pptx 13:24:00 #link https://etherpad.opnfv.org/p/doctor_bps 13:24:02 Gerald_K, Thanks 13:24:09 I got those in to the minutes already 13:24:14 N harm having them twice 13:24:20 No harm 13:24:23 #info Bryan points out that choice of technology for "listener" is important as this will affect the scalability 13:24:31 That too :-) 13:24:35 so just my 2c for now, to me it feels like there is a lot of detail that is not yet captured/reflected in the blueprint as submitted to openstack 13:24:43 sorry. I missed the first part. switched on my IRC too late 13:25:19 @ sgordon: fully agree. is the content in the Etherpad more appropriate ? 13:25:19 Gerald_K: Error: "sgordon:" is not a valid command. 13:25:28 sgordon: fully agree. is the content in the Etherpad more appropriate ? 13:25:42 it's closer 13:25:54 it is likely worth trying to frame in the context of a spec to go with the blueprint 13:25:58 the template for ceilometer is here: 13:26:00 #link http://git.openstack.org/cgit/openstack/ceilometer-specs/tree/specs/template.rst 13:26:04 okay. 13:26:19 in filling out that template i think the detail required will become clear 13:27:03 #info 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 13:27:06 if you have some specific part where you think information is missing, can you pls mark it in the Etherpad ? 13:27:29 #info Dave Neary asked how Ryota plans to co-operate with ETSI NFV, and when we can see an updated draft of the blueprint? 13:27:55 #info Ryota confirms that once the plan is agreed in OPNFV, he will update the blueprint in OpenStack 13:28:37 #info for the Copper blueprints I will be diving into these aspects under the specs repository per the rough blueprints on the wiki, using the openstack template - I suggest that we ensure that the common goals of doctor and copper re event notification are aligned before we go to openstack (optimally) 13:28:38 alignment with ETSI NFV will happen through the companies active in both communities, e.g. DOCOMO 13:28:50 #info Multisite would also like to work together with Doctor on the scale issue 13:29:21 #info since from some experiments rabbitmq works horribly when the number of nodes gets larger 13:29:24 #info can someone drop a link to the blueprint template? 13:29:57 #link http://git.openstack.org/cgit/openstack/ceilometer-specs/tree/specs/template.rst? 13:30:20 zhipeng, another option to consider longer term might be the proton project within apache qpid project 13:30:32 zhipeng, Thanks 13:30:37 sgordon yes I would agree 13:30:38 #link http://qpid.apache.org/proton/ 13:30:51 sgordon that is worth trying out 13:31:04 still wip from an openstack perspective as far as i know 13:31:14 sgordon yap 13:31:35 #info sgordon: another option to consider longer term might be the proton project within apache qpid project 13:31:52 thx Gerald_K :) 13:33:00 #info ideas was to re-use most code from existing alarm evaluator for the new "notification-driven evalutator" 13:33:27 #link http://docs.openstack.org/developer/oslo.messaging/AMQP1.0.html 13:33:39 #info fzdarsky asks what the scaling and timeliness goals are for the solution 13:33:59 #info <1s 13:34:04 #info Ryota responds less than 1s for reacting to server issue 13:35:08 #chair Gerald_K bryan_att zhipeng 13:35:08 Current chairs: Gerald_K bryan_att dneary sgordon zhipeng 13:35:42 #chair fzdarsky jlm iben bin_ 13:35:42 Current chairs: Gerald_K bin_ bryan_att dneary fzdarsky iben jlm sgordon zhipeng 13:36:51 #info More collaboration and review is needed before submitting a blueprint to Ceilometer (overlapping goals with Copper, draft blueprint fitting template) 13:37:41 #info adding my earlier comments - we can go to openstack discussions and the summit with diverse proposals but 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 13:38:01 #topic Project proposal discussions: Multisite and Compass 13:38:24 AFK for a few minutes - can I delegate minute taking please? 13:38:45 bryan_att, zhipeng, ^^^^? 13:39:11 #info takeover from dneary :) 13:39:21 dneary: what does that mean - I no speak IRC 13:39:30 #info Joe Huang discuss about the Multisite proposal 13:39:51 #info Joe Huang discussing keystone failover 13:40:11 away from keyboard 13:40:56 just to re-iterate, bryan_att's last #info is critical 13:41:03 for success 13:41:48 #info Zhipeng introduces new BP for Multisite 13:42:17 #link https://wiki.opnfv.org/requirements_projects/multisite 13:42:32 #info Gerald_K asked about the text below the figure in the Multisite wiiki 13:43:58 zhipeng #info Gerald_K suggests that to edit the wording 13:44:43 #info text should be revised. the listed projects currently are not investigating the multi-site aspects but are focusing on the requirements for single-site deployments 13:45:28 #info need more feedback from the projects that would have multisite requirement:) 13:46:02 bryan_att - did you still have a question about the IRC flow above? 13:46:13 #link https://wiki.opnfv.org/community/openstack?&#opnfv_related_blueprints 13:46:22 #info the last row 13:46:23 #info planned deliverables: Bin HU is missing which subjects/topics the deliverables will address 13:47:49 question: somone mentioned a generic project proposal template or was it a blueprint template? 13:48:18 #info will make more specific description on the planned deliverables of multisite 13:48:38 the reason I ask is that we shuold have a section in there to address the typical questions that come up here such as scalability and I/O capacity. 13:48:39 #info how to work together with the related projects? which working process? 13:49:40 #info are you assuming people from different projects should join the multisite weekly meetings? 13:51:56 #info Howard: we plan to trigger joint meetings by BP proposals 13:53:32 #info looks like kind of an integration project. 13:53:41 #info 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? 13:55:24 #info create a list of teams that would work together on multisite 13:56:24 #info proposal that multisite project is triggering the other teams for specific topics they think are relevant for multi-site, but currently not yet addressed by the individual projects 14:01:37 We need to get teh Perf Test Meeting started 14:04:02 #endmeeting 14:05:07 trevor_intel: Error: Can't start another meeting, one is in progress. Use #endmeeting first. 14:05:34 #endmeeting 14:05:53 Gerald_K can you #endmeeting please? 14:06:10 #endmeeting