-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Daniel Dyer <dan.dye...@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 <l...@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 >> // ✉ l...@enovance.com ☎ +33 1 49 70 99 82 >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> >> > > >------------------------------------------------------------------------ > >_______________________________________________ >Mailing list: https://launchpad.net/~openstack >Post to : openstack@lists.launchpad.net >Unsubscribe : https://launchpad.net/~openstack >More help : https://help.launchpad.net/ListHelp - -- Nick Barcet <nick.bar...@canonical.com> aka: nicolas, nijaba -----BEGIN PGP SIGNATURE----- Version: APG v1.0.8 iGsEAREIACsFAk+r1T8kHE5pY29sYXMgQmFyY2V0IDxuaWNvbGFzQGJhcmNldC5j b20+AAoJEFiD3l2iIpt4QXUAoLJwCIl2vnyb9uTOFfJCH63E2qoNAJ0XkRyeBSty +nXCM+8IxnXGB3TAFg== =3gjy -----END PGP SIGNATURE----- _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
