[openstack-dev] [ceilometer] PTL candidacy
hi folks, less than six months ago, i decided to run for PTL of Ceilometer where my main goal was to support the community of contributors that exists within OpenStack with interests in telemetry[1]. it is under that tenet which i will run again for team lead of Ceilometer. as mentioned previously, we have a diverse set of contributors from across the globe working on various aspects of metering and monitoring and it is my goal to ensure nothing slows them down (myself included). that said, as we look forward to Mitaka, i hope to follow along the path of stability, simplicity and usability. some items i'd like to target are: - rolling upgrades - having a fluid upgrade path for operators is critical to providing a highly available cloud environment for their users. i would like to have a viable solution in Ceilometer that can provide this functionality with zero/minimal performance degradation. - building up events - we started work on adding inline event alarming in Aodh during Liberty, this is something i'd like to improve upon by adding multiple worker support and broader alarming evaluations. also, a common use case for events is to analyse the data for BI. while we allow the ability to query and alarm on events. one useful tool would be the ability to run statistics on events such as the number of instances launched. - optimising collection - we improved ease of use by adding declarative notification support in Liberty. it'd be great if this work could be adopted by projects producing metrics. additionally, we currently have a extremely tight coupling between resource metadata and measurement data. i'd like to evaluate how to loosen this so our data collection and storage is more flexible. - continuing the refactoring - removing deprecated/redundant functionality; it was nice deprecating/deleting stuff, let's keep doing it (within reason)! one possible target would be splitting storage/api, while starting the initial deprecation of v2 metering api. - functional and integration testing - we now have integration and functional test living within our repositories. this should allow us to develop testing easier so it'd be good to broaden the coverage. [1] http://lists.openstack.org/pipermail/openstack-dev/2015-April/060536.html cheers, -- gord __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] PTL candidacy
confirmed On 04/02/2015 04:29 PM, gordon chung wrote: hi, i'd like to announce my candidacy for PTL of Ceilometer. as a quick introduction, i've been a contributor in OpenStack for the past few years and for the majority of that time i've been primarily focused on Ceilometer where i contribute regularly to the project with code[1] and reviews[2]. i'm currently an engineer at Red Hat and have previously worked for eNovance and IBM, where in the latter's case, i helped work on advancing the adoption of cloud auditing practices within the community, which i continue to do. to model myself on past PTLs i've worked with, my main goal as PTL will be to support the community of contributors that exists within OpenStack with interests in telemetry. i believe we have a wide variety of contributors with various expertise in Ceilometer and OpenStack and while differing opinions have arisen, as a collective, we have -- and can continue to -- hash out the ideal solutions. with the politically correct portion all covered, my other interests are: stability, the transition to time-series data modeling aka Gnocchi, and events. - we've made strides in Ceilometer over the past cycles to improve stability by adding HA support, remodeling backends, and removing redundancies in Ceilometer. i want to make sure we remain critical of new changes and always ensure they do not add bloat to Ceilometer. - in regards to data storage, while Ceilometer can be used solely as a data retrieval service, i believe Gnocchi -- the modeling of data as a time-series -- will provide a scalable means to storing measurement data regarding OpenStack[3]. this work, i believe, will be important for those using Ceilometer as a complete solution. - the concept of events was realised by the team at RAX and was worked on further in the last cycle. i hope to see this functionality continue to expand by adding the ability to derive and act on events to allow greater insight into the system. - lastly, i want to emphasise documentation. Ceilometer's scope touches all projects and because of that, it can be difficult to pick up. in Kilo, we started to emphasise the importance of documentation and i hope we continue to do so going forward. [1] https://review.openstack.org/#/q/owner:%22gordon+chung%22+project:openstack/ceilometer,n,z[2] http://russellbryant.net/openstack-stats/ceilometer-reviewers-365.txt[3] http://www.slideshare.net/EoghanGlynn/rdo-hangout-on-gnocchi cheers, gord __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] PTL candidacy
hi, i'd like to announce my candidacy for PTL of Ceilometer. as a quick introduction, i've been a contributor in OpenStack for the past few years and for the majority of that time i've been primarily focused on Ceilometer where i contribute regularly to the project with code[1] and reviews[2]. i'm currently an engineer at Red Hat and have previously worked for eNovance and IBM, where in the latter's case, i helped work on advancing the adoption of cloud auditing practices within the community, which i continue to do. to model myself on past PTLs i've worked with, my main goal as PTL will be to support the community of contributors that exists within OpenStack with interests in telemetry. i believe we have a wide variety of contributors with various expertise in Ceilometer and OpenStack and while differing opinions have arisen, as a collective, we have -- and can continue to -- hash out the ideal solutions. with the politically correct portion all covered, my other interests are: stability, the transition to time-series data modeling aka Gnocchi, and events. - we've made strides in Ceilometer over the past cycles to improve stability by adding HA support, remodeling backends, and removing redundancies in Ceilometer. i want to make sure we remain critical of new changes and always ensure they do not add bloat to Ceilometer. - in regards to data storage, while Ceilometer can be used solely as a data retrieval service, i believe Gnocchi -- the modeling of data as a time-series -- will provide a scalable means to storing measurement data regarding OpenStack[3]. this work, i believe, will be important for those using Ceilometer as a complete solution. - the concept of events was realised by the team at RAX and was worked on further in the last cycle. i hope to see this functionality continue to expand by adding the ability to derive and act on events to allow greater insight into the system. - lastly, i want to emphasise documentation. Ceilometer's scope touches all projects and because of that, it can be difficult to pick up. in Kilo, we started to emphasise the importance of documentation and i hope we continue to do so going forward. [1] https://review.openstack.org/#/q/owner:%22gordon+chung%22+project:openstack/ceilometer,n,z[2] http://russellbryant.net/openstack-stats/ceilometer-reviewers-365.txt[3] http://www.slideshare.net/EoghanGlynn/rdo-hangout-on-gnocchi cheers, gord __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] PTL Candidacy
Folks, I'd like to continue serving as Telemetry PTL for a second cycle. When I took on the role for Juno, I saw some challenges facing the project that would take multi-cycle efforts to resolve, so I'd like to have the opportunity to see that move closer to completion. Over Juno, our focus as a project has necessarily been on addressing the TC gap analysis. We've been successful in ensuring that the agreed gap coverage tasks were completed. The team made great strides in making the sql-alchemy driver a viable option for PoCs and small deployments, getting meaningful Tempest Grenade coverage in place, and writing quality user- and operator-oriented documentation. This has addressed a portion of our usability debt, but as always we need to continue chipping away at that. In parallel, an arms-length effort was kicked off to look at paying down accumulated architectural debt in Ceilometer via a new approach to more lightweight timeseries data storage via the Gnocchi project. This was approached in such a way as to minimize the disruption to the core project. My vision for Kilo would be to shift our focus a bit more onto such longer-terms strategic efforts. Clearly we need to complete the work on Gnocchi and figure out the migration and co-existence issues. In addition, we started a conversation with the Monasca folks at the Juno summit on the commonality between the two projects. Over Kilo I would like to broaden and deepen the collaboration that was first mooted in Atlanta, by figuring out specific incremental steps around converging some common functional areas such as alarming. We can also learn from the experience of the Monasca project in getting the best possible performance out of TSD storage in InfluxDB, or achieving very high throughput messaging via Apache Kafka. There are also cross-project debts facing our community that we need to bring some of our focus to IME. In particular, I'm thinking here about the move towards taking integration test coverage back out of Tempest and into new project-specific functional test suites. Also the oft-proposed, but never yet delivered-upon, notion of contractizing cross-project interactions mediated by notifications. Finally, it's worth noting that our entire community has a big challenge ahead of it in terms of the proposed move towards a new layering structure. If re-elected, I would see myself as an active participant in that discussion, ensuring the interests of the project are positively represented. Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] PTL Candidacy
confirmed On 23/09/14 05:10 AM, Eoghan Glynn wrote: Folks, I'd like to continue serving as Telemetry PTL for a second cycle. When I took on the role for Juno, I saw some challenges facing the project that would take multi-cycle efforts to resolve, so I'd like to have the opportunity to see that move closer to completion. Over Juno, our focus as a project has necessarily been on addressing the TC gap analysis. We've been successful in ensuring that the agreed gap coverage tasks were completed. The team made great strides in making the sql-alchemy driver a viable option for PoCs and small deployments, getting meaningful Tempest Grenade coverage in place, and writing quality user- and operator-oriented documentation. This has addressed a portion of our usability debt, but as always we need to continue chipping away at that. In parallel, an arms-length effort was kicked off to look at paying down accumulated architectural debt in Ceilometer via a new approach to more lightweight timeseries data storage via the Gnocchi project. This was approached in such a way as to minimize the disruption to the core project. My vision for Kilo would be to shift our focus a bit more onto such longer-terms strategic efforts. Clearly we need to complete the work on Gnocchi and figure out the migration and co-existence issues. In addition, we started a conversation with the Monasca folks at the Juno summit on the commonality between the two projects. Over Kilo I would like to broaden and deepen the collaboration that was first mooted in Atlanta, by figuring out specific incremental steps around converging some common functional areas such as alarming. We can also learn from the experience of the Monasca project in getting the best possible performance out of TSD storage in InfluxDB, or achieving very high throughput messaging via Apache Kafka. There are also cross-project debts facing our community that we need to bring some of our focus to IME. In particular, I'm thinking here about the move towards taking integration test coverage back out of Tempest and into new project-specific functional test suites. Also the oft-proposed, but never yet delivered-upon, notion of contractizing cross-project interactions mediated by notifications. Finally, it's worth noting that our entire community has a big challenge ahead of it in terms of the proposed move towards a new layering structure. If re-elected, I would see myself as an active participant in that discussion, ensuring the interests of the project are positively represented. Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] PTL candidacy
On Wed, Apr 02 2014, Gordon Chung wrote: i'd like to announce my candidacy for PTL of Ceilometer. Thanks Gordon! You're really a great candidate and an important Ceilometer contributor! -- Julien Danjou ;; Free Software hacker ;; http://julien.danjou.info signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] PTL candidacy
confirmed On 04/02/2014 04:47 PM, Gordon Chung wrote: hi, i'd like to announce my candidacy for PTL of Ceilometer. as a little background, i've been a contributor to OpenStack for the past year and a half and have been primarily focused on Ceilometer for the past two cycles where i've been a core contributor. i contribute regularly to the project with code [1] and am one of the top reviewers [2]. i am also a developer at IBM where i work on the IBM software standards team, building standards such as the Cloud Audit Data Federation Working Group (CADF) specification. there's a great deal to be discussed at the upcoming summit and i'm sure Ceilometers' contributors and deployers have a lot of ideas. in addition to those, i think some key items to focus on are: - improving collector performance in Ceilometer. this has been a major item in Ceilometer recently as we tried to expand our integration tests in tempest and have found there are inefficiencies in how Ceilometer is collecting data. Ceilometer should be a lightweight service, capable of processing heavy load and we need to ensure it can handle this. i'd like to revisit our models (to ensure our model match what operators require) and build our backends around this so they are highly tuned to writes and reads for these use cases. - improving polling agents. the compute agent currently creates a heavy load on compute-api[3] and the central agent has it's own performance and HA issues... it's something we should really considering looking at. - continue to expand tempest testing in ceilometer. the tempest tests have been helpful in identifying gaps/performance issues and will help later in identifying regression. - review how we log in Ceilometer. we have a very repetitive framework design so our logs can be extremely overwhelming or extremely sparse. some other items to track (depending on resource) are: - enhancing event support. there is a framework for events in Ceilometer but there is work to be done to make it a true monitoring tool. we have a few blueprints existing in Ceilometer that should help. - re-evaluating the alarming service. we currently require two services to run for alarms, a notifier and an evaluator which also depends on the ceilometerclient. there is an interesting bp to move some alarm logic to the pipeline and i think we should take a look at it to see if it provides a cleaner, leaner solution.[4]. if not, we should work on documenting our current implementation. [1] https://review.openstack.org/#/q/owner:chungg+status:merged+project:openstack/ceilometer,n,z [2] http://russellbryant.net/openstack-stats/ceilometer-reviewers-365.txt [3] http://openstack-in-production.blogspot.ca/2014/03/cern-cloud-architecture-update-for.html [4] https://blueprints.launchpad.net/ceilometer/+spec/alarm-pipelines cheers, gordon chung openstack, ibm software standards ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] PTL candidacy
On 04/02/2014 05:47 PM, Gordon Chung wrote: I'd like to announce my candidacy for PTL of Ceilometer. Woot! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] PTL Candidacy
On Sat, Mar 29 2014, Eoghan Glynn wrote: I would like to throw my hat into the ring for the upcoming ceilometer PTL election. […] Thanks for your candidacy Eoghan, I really think you would be a great PTL as you have been a really good, dare I say, deputy these last months. :-) I'm sure you'll be up to the challenges of this next cycle! As far as I'm concerned, I will not run for PTL this cycle. I've been in charge of Ceilometer for a year now, and while I definitely plan to continue working on it, I need more time behind the scene. :) -- Julien Danjou // Free Software hacker // http://julien.danjou.info signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] PTL Candidacy
Hi Folks, I would like to throw my hat into the ring for the upcoming ceilometer PTL election. Over the past three release cycles, I've become increasingly focused on Telemetry in OpenStack, and feel at this stage that I'm in a position to make a positive impact on the project as PTL. We've achieved a lot in taking ceilometer through incubation to become a well-established integrated component. However both technical and organizational challenges remain to be tackled, and I'd like to have the opportunity to be at the helm of that. As PTL, my intended priorities for Juno would include: - addressing the known scalability bottlenecks in ceilometer, paying down accumulated technical debt at both the architectural and micro-levels - driving quality in the ceilometer codebase with a continued emphasis on widening coverage in Tempest, but also testing against more realistic datasets at scale - opening a channel to leverage the real-world experience of cloud operators standing up ceilometer, using that tribal knowledge to guide the project aims and priorities - continuing to develop ceilometer's role as a cross-cutting infrastructure within OpenStack, by seeding further collaboration with emerging projects such as Ironic, TripleO and Tuskar - addressing proliferation issues within ceilometer's growing stable of drivers and inspectors, so that active maintainership and coverage is guaranteed for everything that remains in-tree - driving constant renewal within the core project team, so as to ensure longer term project sustainability by encouraging emerging contributors My commit history: https://review.openstack.org/#/q/owner:eglynn,n,z My review history: https://review.openstack.org/#/q/-owner:eglynn+reviewer:eglynn,n,z Thanks for your consideration! Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] PTL Candidacy
confirmed On 03/29/2014 09:06 AM, Eoghan Glynn wrote: Hi Folks, I would like to throw my hat into the ring for the upcoming ceilometer PTL election. Over the past three release cycles, I've become increasingly focused on Telemetry in OpenStack, and feel at this stage that I'm in a position to make a positive impact on the project as PTL. We've achieved a lot in taking ceilometer through incubation to become a well-established integrated component. However both technical and organizational challenges remain to be tackled, and I'd like to have the opportunity to be at the helm of that. As PTL, my intended priorities for Juno would include: - addressing the known scalability bottlenecks in ceilometer, paying down accumulated technical debt at both the architectural and micro-levels - driving quality in the ceilometer codebase with a continued emphasis on widening coverage in Tempest, but also testing against more realistic datasets at scale - opening a channel to leverage the real-world experience of cloud operators standing up ceilometer, using that tribal knowledge to guide the project aims and priorities - continuing to develop ceilometer's role as a cross-cutting infrastructure within OpenStack, by seeding further collaboration with emerging projects such as Ironic, TripleO and Tuskar - addressing proliferation issues within ceilometer's growing stable of drivers and inspectors, so that active maintainership and coverage is guaranteed for everything that remains in-tree - driving constant renewal within the core project team, so as to ensure longer term project sustainability by encouraging emerging contributors My commit history: https://review.openstack.org/#/q/owner:eglynn,n,z My review history: https://review.openstack.org/#/q/-owner:eglynn+reviewer:eglynn,n,z Thanks for your consideration! Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
