Difference between revisions of "Telemetry/RoadMap"
Gordon chung (talk | contribs) (Created page with "= Road Map = Current (Mitaka) Cycle Targets: https://blueprints.launchpad.net/ceilometer/mitaka == Priority Work Items == The following are high priority items targeted for...") |
Gordon chung (talk | contribs) m (→Open Work Items) |
||
Line 12: | Line 12: | ||
* https://launchpad.net/~gnocchi-drivers/+members#active | * https://launchpad.net/~gnocchi-drivers/+members#active | ||
− | === Aodh (alarming) === | + | === Aodh (alarming) ===* revisit gnocchi resource definition (dispatcher side: https://review.openstack.org/#/c/202500/) |
* in-tree functional tests | * in-tree functional tests | ||
+ | * new aodhclient | ||
+ | ** based on gnocchiclient to ensure we use latest and greatest. | ||
+ | ** syntax needs to be simplified, too many options. | ||
+ | * migrate tempest plugin | ||
+ | |||
=== Ceilometer (data collection) === | === Ceilometer (data collection) === | ||
* add elasticsearch functional gate | * add elasticsearch functional gate | ||
* Polling schema - separate polling logic from pipeline | * Polling schema - separate polling logic from pipeline | ||
+ | ** new polling definition file https://etherpad.openstack.org/p/mitaka-telemetry-polling | ||
+ | * refine polling | ||
+ | ** global caching between pollsters (https://etherpad.openstack.org/p/mitaka-telemetry-polling) | ||
+ | * Cache everything everywhere, all the time | ||
+ | ** in particular dogpile.cache (because it is already used in Keystone) in the gnocchi dispatcher in ceilometer to cache resources (see [https://review.openstack.org/#/c/203109/ POC]) | ||
+ | ** add to sql driver | ||
* rally tests | * rally tests | ||
+ | * migrate tempest plugin | ||
+ | |||
=== Gnocchi (metric storage) === | === Gnocchi (metric storage) === | ||
* indexer sharding support | * indexer sharding support | ||
− | * | + | * dynamic resource creation |
* benchmark | * benchmark | ||
+ | * migrate tempest plugin | ||
− | + | == Future Targets == | |
These ideas have been discussed/introduced at a high-level. They are areas of interests for the users/developers of Ceilometer but still require discussion. Proposals for concrete work items related to these items are welcomed for future cycles: | These ideas have been discussed/introduced at a high-level. They are areas of interests for the users/developers of Ceilometer but still require discussion. Proposals for concrete work items related to these items are welcomed for future cycles: | ||
Line 42: | Line 56: | ||
* Use specific configuration to load selected stevedore extensions, not all of them | * Use specific configuration to load selected stevedore extensions, not all of them | ||
** remove stevedore plugins out of tree | ** remove stevedore plugins out of tree | ||
− | |||
− | |||
* Add more complete evaluation of the upgrade process in the grenade plugin. | * Add more complete evaluation of the upgrade process in the grenade plugin. | ||
* Notification and pollster driven functional/integration tests. | * Notification and pollster driven functional/integration tests. | ||
− | + | == Past Cycles == | |
* Liberty: https://blueprints.launchpad.net/ceilometer/liberty | * Liberty: https://blueprints.launchpad.net/ceilometer/liberty | ||
* Kilo: https://blueprints.launchpad.net/ceilometer/kilo | * Kilo: https://blueprints.launchpad.net/ceilometer/kilo | ||
* Juno: https://blueprints.launchpad.net/ceilometer/juno | * Juno: https://blueprints.launchpad.net/ceilometer/juno |
Revision as of 18:30, 13 November 2015
Contents
Road Map
Current (Mitaka) Cycle Targets: https://blueprints.launchpad.net/ceilometer/mitaka
Priority Work Items
The following are high priority items targeted for the current cycle that require owners:
Open Work Items
The following is a list of work items that have been approved conceptually and can be targeted for the current development cycle. For more information on a item, contact us on openstack-dev mailing list or on freenode at #openstack-telemetry. The current list of core contributors can be found at each projects respective page:
- https://launchpad.net/~aodh-drivers/+members#active
- https://launchpad.net/~ceilometer-drivers/+members#active
- https://launchpad.net/~gnocchi-drivers/+members#active
=== Aodh (alarming) ===* revisit gnocchi resource definition (dispatcher side: https://review.openstack.org/#/c/202500/)
- in-tree functional tests
- new aodhclient
- based on gnocchiclient to ensure we use latest and greatest.
- syntax needs to be simplified, too many options.
- migrate tempest plugin
Ceilometer (data collection)
- add elasticsearch functional gate
- Polling schema - separate polling logic from pipeline
- new polling definition file https://etherpad.openstack.org/p/mitaka-telemetry-polling
- refine polling
- global caching between pollsters (https://etherpad.openstack.org/p/mitaka-telemetry-polling)
- Cache everything everywhere, all the time
- in particular dogpile.cache (because it is already used in Keystone) in the gnocchi dispatcher in ceilometer to cache resources (see POC)
- add to sql driver
- rally tests
- migrate tempest plugin
Gnocchi (metric storage)
- indexer sharding support
- dynamic resource creation
- benchmark
- migrate tempest plugin
Future Targets
These ideas have been discussed/introduced at a high-level. They are areas of interests for the users/developers of Ceilometer but still require discussion. Proposals for concrete work items related to these items are welcomed for future cycles:
- log processing
- application level monitoring
- project defined meters - leveraging declarative meters
- group based configuration control - connect tooz to manage configuration and allow for better control of configuration updates.
- Nova
- the end of nova polling (http://lists.openstack.org/pipermail/openstack-dev/2015-June/067589.html)
- nova cell metrics
- nova availability zone metrics
- batching support for recording of event and meter data
- project level pipeline control. enable ability to poll at different frequencies per project.
- granular ttl control (project level / meter level)
- CADF event indexer - generic definition to index all CADF events
- stop using WSME in ceilometer and aodh
- Release to PyPI
- Use specific configuration to load selected stevedore extensions, not all of them
- remove stevedore plugins out of tree
- Add more complete evaluation of the upgrade process in the grenade plugin.
- Notification and pollster driven functional/integration tests.