On Thu, May 10, 2012 at 12:17 AM, Daniel Dyer <[email protected]> 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 <[email protected]> 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 >> // ✉ [email protected] ☎ +33 1 49 70 99 82 >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> >> > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
