openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

On Thu, May 10, 2012 at 12:17 AM, Daniel Dyer <dan.dyer00@xxxxxxxxx> wrote:

> A question/comment about the scope of the schema or maybe the
> architecture. Assuming the services will provide the instrumentation to
> populate the raw metric data, it seems likely that you will need to define
> an interface between the services/agents
> that are providing the data and the metering system which stores the
> generated metric data in the database (as opposed to having the services
> write directly to the DB). Is the schema intended to be this kind of
> interop format between the services and
> the meter's datastore or just the end result of the storage?
>

It may be both, at first, but we also may find some benefit to letting them
diverge later so I don't think we need to make it a hard requirement.


>
> Thanks,
> Dan Dyer
>
> On Thu, May 3, 2012 at 11:10 AM, Loic Dachary <loic@xxxxxxxxxxxx> wrote:
>
>>  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
>> athttp://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
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>