#opnfv-meeting: Technical review meeting - projects and blueprints

Meeting started by dneary at 13:07:32 UTC (full logs).

Meeting summary

  1. Blueprint review: Doctor (dneary, 13:08:43)
    1. Bryan Sullivan (bryan_att, 13:08:45)
    2. Steve Gordon (sgordon, 13:08:54)
    3. https://etherpad.opnfv.org/p/doctor_bps (dneary, 13:08:56)
    4. can someone drop a link to the docs for the notification bus feature of openstack? (bryan_att, 13:10:00)
    5. https://wiki.opnfv.org/_media/doctor/opnfv_ceilometer_bp_from_doctor.20150319.pptx (dneary, 13:11:08)
    6. John Messenger (jlm, 13:11:51)
    7. https://wiki.openstack.org/wiki/Oslo/Messaging (bryan_att, 13:12:09)
    8. Ryota Mibu presents the current plan for Doctor based on the slide deck above (dneary, 13:12:10)
    9. I believe Oslo is what is being referred to (bryan_att, 13:12:36)
    10. http://docs.openstack.org/developer/ceilometer/architecture.html (sgordon, 13:17:27)
    11. 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 (dneary, 13:18:18)
    12. 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 (dneary, 13:21:51)
    13. https://wiki.openstack.org/wiki/Oslo/Messaging#Transport_Driver_API (sgordon, 13:22:27)
    14. https://wiki.opnfv.org/_media/doctor/opnfv_ceilometer_bps_from_doctor.20150319.pptx (Gerald_K, 13:23:51)
    15. https://etherpad.opnfv.org/p/doctor_bps (Gerald_K, 13:24:00)
    16. Bryan points out that choice of technology for "listener" is important as this will affect the scalability (Gerald_K, 13:24:23)
    17. http://git.openstack.org/cgit/openstack/ceilometer-specs/tree/specs/template.rst (sgordon, 13:26:00)
    18. 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 (bryan_att, 13:27:03)
    19. Dave Neary asked how Ryota plans to co-operate with ETSI NFV, and when we can see an updated draft of the blueprint? (dneary, 13:27:29)
    20. Ryota confirms that once the plan is agreed in OPNFV, he will update the blueprint in OpenStack (dneary, 13:27:55)
    21. 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) (bryan_att, 13:28:37)
    22. Multisite would also like to work together with Doctor on the scale issue (zhipeng, 13:28:50)
    23. since from some experiments rabbitmq works horribly when the number of nodes gets larger (zhipeng, 13:29:21)
    24. can someone drop a link to the blueprint template? (bryan_att, 13:29:24)
    25. http://git.openstack.org/cgit/openstack/ceilometer-specs/tree/specs/template.rst? (zhipeng, 13:29:57)
    26. http://qpid.apache.org/proton/ (sgordon, 13:30:38)
    27. sgordon: another option to consider longer term might be the proton project within apache qpid project (Gerald_K, 13:31:35)
    28. ideas was to re-use most code from existing alarm evaluator for the new "notification-driven evalutator" (Gerald_K, 13:33:00)
    29. http://docs.openstack.org/developer/oslo.messaging/AMQP1.0.html (sgordon, 13:33:27)
    30. fzdarsky asks what the scaling and timeliness goals are for the solution (dneary, 13:33:39)
    31. <1s (Gerald_K, 13:33:59)
    32. Ryota responds less than 1s for reacting to server issue (dneary, 13:34:04)
    33. More collaboration and review is needed before submitting a blueprint to Ceilometer (overlapping goals with Copper, draft blueprint fitting template) (dneary, 13:36:51)
    34. 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 (bryan_att, 13:37:41)

  2. Project proposal discussions: Multisite and Compass (dneary, 13:38:01)
    1. takeover from dneary :) (zhipeng, 13:39:11)
    2. Joe Huang discuss about the Multisite proposal (zhipeng, 13:39:30)
    3. Joe Huang discussing keystone failover (sgordon, 13:39:51)
    4. Zhipeng introduces new BP for Multisite (zhipeng, 13:41:48)
    5. https://wiki.opnfv.org/requirements_projects/multisite (bryan_att, 13:42:17)
    6. Gerald_K asked about the text below the figure in the Multisite wiiki (zhipeng, 13:42:32)
    7. 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 (Gerald_K, 13:44:43)
    8. need more feedback from the projects that would have multisite requirement:) (zhipeng, 13:45:28)
    9. https://wiki.opnfv.org/community/openstack?&#opnfv_related_blueprints (zhipeng, 13:46:13)
    10. the last row (zhipeng, 13:46:22)
    11. planned deliverables: Bin HU is missing which subjects/topics the deliverables will address (Gerald_K, 13:46:23)
    12. will make more specific description on the planned deliverables of multisite (zhipeng, 13:48:18)
    13. how to work together with the related projects? which working process? (Gerald_K, 13:48:39)
    14. are you assuming people from different projects should join the multisite weekly meetings? (Gerald_K, 13:49:40)
    15. Howard: we plan to trigger joint meetings by BP proposals (Gerald_K, 13:51:56)
    16. looks like kind of an integration project. (Gerald_K, 13:53:32)
    17. 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? (bryan_att, 13:53:41)
    18. create a list of teams that would work together on multisite (zhipeng, 13:55:24)
    19. 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 (Gerald_K, 13:56:24)


Meeting ended at 14:06:10 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. dneary (29)
  2. Gerald_K (19)
  3. sgordon (18)
  4. zhipeng (17)
  5. bryan_att (12)
  6. collabot (8)
  7. iben (3)
  8. trevor_intel (2)
  9. ChrisPriceAB (2)
  10. jlm (2)
  11. B_Smith_ (1)
  12. fzdarsky (1)
  13. bin_ (0)


Generated by MeetBot 0.1.4.