openstack team mailing list archive

[Loic Dachary <loic@xxxxxxxxxxxx>]

On 05/03/2012 02:22 PM, Loic Dachary wrote:
> Hi,
>
> The metering project team holds a meeting in #openstack-meeting, Thursdays at 1600 UTC <http://www.timeanddate.com/worldclock/fixedtime.html?hour=16&min=0&sec=0>. Everyone is welcome.
> I propose an agenda based on the discussions we had on this list.
>
> http://wiki.openstack.org/Meetings/MeteringAgenda
> Topic : schema and counter definitions
>
>  * counter definitions
>    * Proposed http://wiki.openstack.org/EfficientMetering#Counters
>  * schema definition
>    * Proposed http://wiki.openstack.org/EfficientMetering#Storage
>  * discuss storage assumptions
>    * the storage will store all events
>    * no aggregated value is permanently stored
>  * discuss API assumptions
>    * the API provide a sum() function to aggregate values
>    * the API may transparently store results of the sum function in a cache
>  * discuss event collection
>    * events are collected from a components when possible
>    * ceilometer agent is installed on a node when the a component does not provide the value
>    * contribute to the component instead of developping a ceilometer agent plugin
>  * engaging discussions with core components
>    * nova
>    * cinder
>    * glance
>    * swift
>    * quantum
>  *  open discussion
>
For the record, the first two points used all the time but that was the goal of the meeting. The other points would have been nice to discuss but can each be turned into a mailing list thread ;-)

==========================
#openstack-meeting Meeting
==========================


Meeting started by dachary at 16:00:16 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-03-16.00.log.html
.



Meeting summary
---------------

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

* meeting organisation  (dachary, 16:01:03)
  * This is 1/5 meetings to decide the architecture of the Metering
    project https://launchpad.net/ceilometer  (dachary, 16:01:03)
  * Today's focus is on the definition of the counters / meters and the
    associated schema for the storage  (dachary, 16:01:03)
  * 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)
  * The meeting is time boxed and there will not be enough time to
    introduce inovative ideas and research for solutions.  (dachary,
    16:01:03)
  * The debate will be about the pro and cons of the options already
    discussed on the mailing list.  (dachary, 16:01:03)
  * LINK: https://lists.launchpad.net/openstack/msg10810.html  (dachary,
    16:01:03)

* counter definitions  (dachary, 16:02:10)
  * Proposed http://wiki.openstack.org/EfficientMetering#Counters
    (dachary, 16:02:10)
  * ACTION: dachary fix the note for net_float still talks about "number
    of floating IPs"  (dachary, 16:09:18)
  * 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)
  * ACTION: dachary add note about the fact that the resource_id for the
    object count is the container_id  (dachary, 16:21:44)
  * LINK: http://wiki.openstack.org/EfficientMetering#Counters is agreed
    on, provided the actions listed above are carried out.  (dachary,
    16:25:35)
  * ACTION: jd___ document the resource_id for each counter  (dachary,
    16:30:33)
  * 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)
  * AGREED: s/counter/meter/  (dachary, 16:37:11)
  * LINK: http://wiki.openstack.org/EfficientMetering#Counters is agreed
    on, provided the actions listed above are carried out. ?  (dachary,
    16:37:38)
  * AGREED: http://wiki.openstack.org/EfficientMetering#Counters is
    agreed on, provided the actions listed above are carried out. ?
    (dachary, 16:38:52)

* schema definition  (dachary, 16:39:05)
  * Proposed http://wiki.openstack.org/EfficientMetering#Storage
    (dachary, 16:39:05)
  * 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)
  * ACTION: nijaba describe the source field rationale and use case,
    initiate a thread to validate its use.  (dachary, 16:50:26)
  * 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)
  * ACTION: jd___ update the documentation  (dachary, 16:53:48)
  * ACTION: jd___ document the resource_id for each counter  (dachary,
    16:54:10)

* discuss API assumptions  (dachary, 16:54:51)

* open discussion  (dachary, 16:55:19)



Meeting ended at 17:00:05 UTC.



Action items, by person
-----------------------

* dachary
  * dachary fix the note for net_float still talks about "number of
    floating IPs"
  * dachary add note about the fact that the resource_id for the object
    count is the container_id
* jd___
  * jd___ include Number of object in Swift, Number of containers in
    Swift, Number of GET/HEAD/PUT/POST requests in Swift in the table
  * jd___ document the resource_id for each counter
  * 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
  * 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"
  * jd___ update the documentation
  * jd___ document the resource_id for each counter
* nijaba
  * nijaba describe the source field rationale and use case, initiate a
    thread to validate its use.



-- 
Loïc Dachary         Chief Research Officer
// eNovance labs   http://labs.enovance.com
// ? loic@xxxxxxxxxxxx  ? +33 1 49 70 99 82