Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Daniel Dyer <dan.dyer00 at gmail.com> 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?

Just the end result, we have a discussion and decision on May 24th regarding the internal API for the agents to use when communicating on the queue.

http://wiki.openstack.org/Meetings/MeteringAgenda#Meeting%20topics

>Thanks,
>Dan Dyer
>
>On Thu, May 3, 2012 at 11:10 AM, Loic Dachary <loic at enovance.com>
>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 at enovance.com  ☎ +33 1 49 70 99 82
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Mailing list: https://launchpad.net/~openstack
>Post to     : openstack at lists.launchpad.net
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp


- --
Nick Barcet <nick.barcet at canonical.com>
aka: nicolas, nijaba
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.8

iGsEAREIACsFAk+r1T8kHE5pY29sYXMgQmFyY2V0IDxuaWNvbGFzQGJhcmNldC5j
b20+AAoJEFiD3l2iIpt4QXUAoLJwCIl2vnyb9uTOFfJCH63E2qoNAJ0XkRyeBSty
+nXCM+8IxnXGB3TAFg==
=3gjy
-----END PGP SIGNATURE-----