Re: [Openstack] [Metering] Meeting agenda for today 16:00 UTC (May 3rd, 2012)
-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 UTChttp://www.timeanddate.com/worldclock/fixedtime.html?hour=16min=0sec=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
Re: [Openstack] [Metering] Meeting agenda for today 16:00 UTC (May 3rd, 2012)
On Thu, May 10, 2012 at 12:17 AM, 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? 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 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 UTChttp://www.timeanddate.com/worldclock/fixedtime.html?hour=16min=0sec=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) *
Re: [Openstack] [Metering] Meeting agenda for today 16:00 UTC (May 3rd, 2012)
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? 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 UTChttp://www.timeanddate.com/worldclock/fixedtime.html?hour=16min=0sec=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:
[Openstack] [Metering] Meeting agenda for today 16:00 UTC (May 3rd, 2012)
Hi, The metering project team holds a meeting in #openstack-meeting, Thursdays at 1600 UTC http://www.timeanddate.com/worldclock/fixedtime.html?hour=16min=0sec=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 Cheers -- 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
