#openstack-meeting Meeting

Meeting started by dachary at 16:00:16 UTC (full logs).

Meeting summary

  1. actions from previous meetings (dachary, 16:00:36)
    1. creation of the ceilometer project (dachary, 16:00:36)
    2. The repository for the ceilometer project has been created (dachary, 16:00:36)
    3. https://github.com/stackforge/ceilometer (dachary, 16:00:36)
    4. and the first commit was successfully reviewed and merged today https://review.stackforge.org/#/c/25/ (dachary, 16:00:37)

  2. meeting organisation (dachary, 16:01:03)
    1. This is 1/5 meetings to decide the architecture of the Metering project https://launchpad.net/ceilometer (dachary, 16:01:03)
    2. Today's focus is on the definition of the counters / meters and the associated schema for the storage (dachary, 16:01:03)
    3. It is the conclusion of the discussions held on the mailing list and the goal is to make a final choice that will then be implemented. (dachary, 16:01:03)
    4. The meeting is time boxed and there will not be enough time to introduce inovative ideas and research for solutions. (dachary, 16:01:03)
    5. The debate will be about the pro and cons of the options already discussed on the mailing list. (dachary, 16:01:03)
    6. https://lists.launchpad.net/openstack/msg10810.html (dachary, 16:01:03)

  3. counter definitions (dachary, 16:02:10)
    1. Proposed http://wiki.openstack.org/EfficientMetering#Counters (dachary, 16:02:10)
    2. ACTION: dachary fix the note for net_float still talks about "number of floating IPs" (dachary, 16:09:18)
    3. ACTION: jd___ include Number of object in Swift, Number of containers in Swift, Number of GET/HEAD/PUT/POST requests in Swift in the table (dachary, 16:10:11)
    4. ACTION: dachary add note about the fact that the resource_id for the object count is the container_id (dachary, 16:21:44)
    5. http://wiki.openstack.org/EfficientMetering#Counters is agreed on, provided the actions listed above are carried out. (dachary, 16:25:35)
    6. ACTION: jd___ document the resource_id for each counter (dachary, 16:30:33)
    7. ACTION: jd___ describes the general table schema and then something that says for each counter exactly what goes in the fields of that table and show how secondary field counters are recorded in the in the schema too (dachary, 16:33:27)
    8. AGREED: s/counter/meter/ (dachary, 16:37:11)
    9. http://wiki.openstack.org/EfficientMetering#Counters is agreed on, provided the actions listed above are carried out. ? (dachary, 16:37:38)
    10. AGREED: http://wiki.openstack.org/EfficientMetering#Counters is agreed on, provided the actions listed above are carried out. ? (dachary, 16:38:52)

  4. schema definition (dachary, 16:39:05)
    1. Proposed http://wiki.openstack.org/EfficientMetering#Storage (dachary, 16:39:05)
    2. ACTION: jd___ clarify / document the fact that the secondary field or the resource_id field carries the IP/VIF for the meters related to network so that they can be "per IP" (dachary, 16:40:42)
    3. ACTION: nijaba describe the source field rationale and use case, initiate a thread to validate its use. (dachary, 16:50:26)
    4. AGREED: the fields should be source (to be discussed), user_id, project_id, resource_id, counter_type, counter_volume, counter_duration, counter_datetime, secondary type / payload, message_signature, message_id ? (dachary, 16:53:20)
    5. ACTION: jd___ update the documentation (dachary, 16:53:48)
    6. ACTION: jd___ document the resource_id for each counter (dachary, 16:54:10)

  5. discuss API assumptions (dachary, 16:54:51)
  6. open discussion (dachary, 16:55:19)


Meeting ended at 17:00:05 UTC (full logs).

Action items

  1. dachary fix the note for net_float still talks about "number of floating IPs"
  2. jd___ include Number of object in Swift, Number of containers in Swift, Number of GET/HEAD/PUT/POST requests in Swift in the table
  3. dachary add note about the fact that the resource_id for the object count is the container_id
  4. jd___ document the resource_id for each counter
  5. jd___ describes the general table schema and then something that says for each counter exactly what goes in the fields of that table and show how secondary field counters are recorded in the in the schema too
  6. jd___ clarify / document the fact that the secondary field or the resource_id field carries the IP/VIF for the meters related to network so that they can be "per IP"
  7. nijaba describe the source field rationale and use case, initiate a thread to validate its use.
  8. jd___ update the documentation
  9. jd___ document the resource_id for each counter


Action items, by person

  1. dachary
    1. dachary fix the note for net_float still talks about "number of floating IPs"
    2. dachary add note about the fact that the resource_id for the object count is the container_id
  2. jd___
    1. jd___ include Number of object in Swift, Number of containers in Swift, Number of GET/HEAD/PUT/POST requests in Swift in the table
    2. jd___ document the resource_id for each counter
    3. jd___ describes the general table schema and then something that says for each counter exactly what goes in the fields of that table and show how secondary field counters are recorded in the in the schema too
    4. jd___ clarify / document the fact that the secondary field or the resource_id field carries the IP/VIF for the meters related to network so that they can be "per IP"
    5. jd___ update the documentation
    6. jd___ document the resource_id for each counter
  3. nijaba
    1. nijaba describe the source field rationale and use case, initiate a thread to validate its use.


People present (lines said)

  1. dachary (118)
  2. dhellmann (74)
  3. nijaba (50)
  4. flacoste (18)
  5. jd___ (14)
  6. Aswad_ (7)
  7. flacoste_ipod (6)
  8. zinux (4)
  9. openstack (4)
  10. whitt (1)


Generated by MeetBot 0.1.4.