Re: [openstack-dev] [all] The future of the integrated release

2014-08-07 Thread Eoghan Glynn
Multidisciplinary training rules! As an architect with field experience building roads, sidewalks, roofs, city planning (and training in lean manufacturing and services) I think I can have a say ;) You're not really introducing a successful Kanban here, you're just clarifying that there

Re: [openstack-dev] [all] The future of the integrated release

2014-08-07 Thread Eoghan Glynn
If we try to limit the number of WIP slots, then surely aspiring contributors will simply work around that restriction by preparing the code they're interested in on their own private branches, or in their github forks? OK, some pragmatic contributors will adjust their priorities to

Re: [openstack-dev] introducing cyclops

2014-08-07 Thread Eoghan Glynn
Dear All, Let me use my first post to this list to introduce Cyclops and initiate a discussion towards possibility of this platform as a future incubated project in OpenStack. We at Zurich university of Applied Sciences have a python project in open source (Apache 2 Licensing) that

Re: [openstack-dev] [all] The future of the integrated release

2014-08-07 Thread Eoghan Glynn
On 08/07/2014 01:41 PM, Eoghan Glynn wrote: My point was simply that we don't have direct control over the contributors' activities This is not correct and I've seen it repeated too often to let it go uncorrected: we (the OpenStack project as a whole) have a lot of control over

Re: [openstack-dev] [all] The future of the integrated release

2014-08-09 Thread Eoghan Glynn
We seem to be unable to address some key issues in the software we produce, and part of it is due to strategic contributors (and core reviewers) being overwhelmed just trying to stay afloat of what's happening. For such projects, is it time for a pause ? Is it time to define key cycle

[openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

2014-08-09 Thread Eoghan Glynn
Hi Folks, Dina Belova has recently landed some infra patches[1,2] to create an experimental mongodb-based Tempest job. This effectively just overrides the ceilometer storage backend config so that mongodb is used instead of sql-alchemy. The new job has been running happily for a few days so I'd

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

2014-08-09 Thread Eoghan Glynn
Hi Folks, Dina Belova has recently landed some infra patches[1,2] to create an experimental mongodb-based Tempest job. This effectively just overrides the ceilometer storage backend config so that mongodb is used instead of sql-alchemy. The new job has been running happily for a

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

2014-08-09 Thread Eoghan Glynn
, Eoghan Glynn egl...@redhat.com wrote: Hi Folks, Dina Belova has recently landed some infra patches[1,2] to create an experimental mongodb-based Tempest job. This effectively just overrides the ceilometer storage backend config so that mongodb is used instead of sql-alchemy. The new job

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

2014-08-09 Thread Eoghan Glynn
+2 from me, More mongodb adoption (as stated) when it's questionable legally doesn't seem like a good long term strategy (I know it will/does impact yahoo adopting or using ceilometer...). Is this another one of those tactical changes that we keep on making that ends up being yet another

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

2014-08-09 Thread Eoghan Glynn
-ballpark performance characteristics to mongodb. Cheers, Eoghan Just my 2cents. Sent from my really tiny device... On Aug 9, 2014, at 10:53 AM, Eoghan Glynn egl...@redhat.com wrote: +2 from me, More mongodb adoption (as stated) when it's questionable legally doesn't seem

Re: [openstack-dev] [tc][ceilometer] Some background on the gnocchi project

2014-08-11 Thread Eoghan Glynn
concrete progress on that score. I hope that provides enough detail to answer to your question? Cheers, Eoghan Thanks, Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Eoghan

Re: [openstack-dev] [tc][ceilometer] Some background on the gnocchi project

2014-08-11 Thread Eoghan Glynn
On 8/11/2014 4:22 PM, Eoghan Glynn wrote: Hi Eoghan, Thanks for the note below. However, one thing the overview below does not cover is why InfluxDB ( http://influxdb.com/ ) is not being leveraged. Many folks feel that this technology is a viable solution for the problem space

Re: [openstack-dev] [tc][ceilometer] Some background on the gnocchi project

2014-08-11 Thread Eoghan Glynn
On 8/11/2014 4:22 PM, Eoghan Glynn wrote: Hi Eoghan, Thanks for the note below. However, one thing the overview below does not cover is why InfluxDB ( http://influxdb.com/ ) is not being leveraged. Many folks feel that this technology is a viable solution for the problem space

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

2014-08-11 Thread Eoghan Glynn
Ignoring the question of is it ok to say: 'to run ceilometer in any sort of non-trivial deployment you must manager yet another underlying service, mongodb' I would prefer not adding an addition gate variant to all projects. With the effort to reduce the number of gate variants we have [0] I

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

2014-08-11 Thread Eoghan Glynn
So would we: (a) add a new integrated-gate-ceilometer project-template to [1], in the style of integrated-gate-neutron or integrated-gate-sahara, which would replicate the main integrated-gate template but with the addition of

Re: [openstack-dev] [tc][ceilometer] Some background on the gnocchi project

2014-08-12 Thread Eoghan Glynn
Doesn't InfluxDB do the same? InfluxDB stores timeseries data primarily. Gnocchi in intended to store strongly-typed OpenStack resource representations (instance, images, etc.) in addition to providing a means to access timeseries data associated with those resources. So to

Re: [openstack-dev] [all] The future of the integrated release

2014-08-12 Thread Eoghan Glynn
It seems like this is exactly what the slots give us, though. The core review team picks a number of slots indicating how much work they think they can actually do (less than the available number of blueprints), and then blueprints queue up to get a slot based on priorities and turnaround

Re: [openstack-dev] [all] The future of the integrated release

2014-08-13 Thread Eoghan Glynn
One thing I'm not seeing shine through in this discussion of slots is whether any notion of individual cores, or small subsets of the core team with aligned interests, can champion blueprints that they have a particular interest in. I think that's because we've focussed in this

Re: [openstack-dev] [all] The future of the integrated release

2014-08-13 Thread Eoghan Glynn
It seems like this is exactly what the slots give us, though. The core review team picks a number of slots indicating how much work they think they can actually do (less than the available number of blueprints), and then blueprints queue up to get a slot based on priorities and

Re: [openstack-dev] [all] The future of the integrated release

2014-08-13 Thread Eoghan Glynn
At the end of the day, that's probably going to mean saying No to more things. Everytime I turn around everyone wants the TC to say No to things, just not to their particular thing. :) Which is human nature. But I think if we don't start saying No to more things we're going to end up

Re: [openstack-dev] [all] The future of the integrated release

2014-08-13 Thread Eoghan Glynn
Divert all cross project efforts from the following projects so we can focus our cross project resources. Once we are in a bitter place we can expand our cross project resources to cover these again. This doesn't mean removing anything. * Sahara * Trove * Tripleo You write

Re: [openstack-dev] [all] The future of the integrated release

2014-08-14 Thread Eoghan Glynn
Letting the industry field-test a project and feed their experience back into the community is a slow process, but that is the best measure of a project's success. I seem to recall this being an implicit expectation a few years ago, but haven't seen it discussed in a while. I think

Re: [openstack-dev] [all] The future of the integrated release

2014-08-14 Thread Eoghan Glynn
Additional cross-project resources can be ponied up by the large contributor companies, and existing cross-project resources are not necessarily divertable on command. Sure additional cross-project resources can and need to be ponied up, but I am doubtful that will be enough. OK, so

Re: [openstack-dev] [all] The future of the integrated release

2014-08-15 Thread Eoghan Glynn
But, if someone asked me what they should use for metering today, I'd point them towards Monasca in a heartbeat. FWIW my view is that Monasca is an interesting emerging project, with a team accreting around it that seems to be interested in collaboration. We've had ongoing discussions with

Re: [openstack-dev] [all] The future of the integrated release

2014-08-20 Thread Eoghan Glynn
Additional cross-project resources can be ponied up by the large contributor companies, and existing cross-project resources are not necessarily divertable on command. Sure additional cross-project resources can and need to be ponied up, but I am doubtful that will be enough.

Re: [openstack-dev] [ceilometer] indicating sample provenance

2014-08-21 Thread Eoghan Glynn
One of the outcomes from Juno will be horizontal scalability in the central agent and alarm evaluator via partitioning[1]. The compute agent will get the same capability if you choose to use it, but it doesn't make quite as much sense. I haven't investigated the alarm evaluator side

Re: [openstack-dev] [Ironic] (Non-)consistency of the Ironic hash ring implementation

2014-09-03 Thread Eoghan Glynn
On 09/02/2014 11:33 PM, Robert Collins wrote: The implementation in ceilometer is very different to the Ironic one - are you saying the test you linked fails with Ironic, or that it fails with the ceilometer code today? Disclaimer: in Ironic terms, node = conductor, key = host The

Re: [openstack-dev] [Ironic] (Non-)consistency of the Ironic hash ring implementation

2014-09-04 Thread Eoghan Glynn
The implementation in ceilometer is very different to the Ironic one - are you saying the test you linked fails with Ironic, or that it fails with the ceilometer code today? Disclaimer: in Ironic terms, node = conductor, key = host The test I linked fails with Ironic hash ring

Re: [openstack-dev] [all] Design Summit reloaded

2014-09-04 Thread Eoghan Glynn
Hi everyone, I've been thinking about what changes we can bring to the Design Summit format to make it more productive. I've heard the feedback from the mid-cycle meetups and would like to apply some of those ideas for Paris, within the constraints we have (already booked space and time).

Re: [openstack-dev] [all] Design Summit reloaded

2014-09-04 Thread Eoghan Glynn
Am I missing some compelling advantage of moving all these emergent project-specific meetups to the Friday? One is that due to space limitations, we won't have nearly as many pods as in Atlanta (more like half or a third of them). Without one pod per program, the model breaks a bit.

Re: [openstack-dev] [Ceilometer] Adding Nejc Saje to ceilometer-core

2014-09-11 Thread Eoghan Glynn
Hi, Nejc has been doing a great work and has been very helpful during the Juno cycle and his help is very valuable. I'd like to propose that we add Nejc Saje to the ceilometer-core group. Please, dear ceilometer-core members, reply with your votes! A hearty +1 for me, Nejc has made a

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-11 Thread Eoghan Glynn
As you all know, there has recently been several very active discussions around how to improve assorted aspects of our development process. One idea that was brought up is to come up with a list of cycle goals/project priorities for Kilo [0]. To that end, I would like to propose an

Re: [openstack-dev] [Ceilometer] Adding Dina Belova to ceilometer-core

2014-09-11 Thread Eoghan Glynn
Hi, Dina has been doing a great work and has been very helpful during the Juno cycle and her help is very valuable. She's been doing a lot of reviews and has been very active in our community. I'd like to propose that we add Dina Belova to the ceilometer-core group, as I'm convinced

Re: [openstack-dev] [all] Design Summit planning

2014-09-12 Thread Eoghan Glynn
I visited the Paris Design Summit space on Monday and confirmed that it should be possible to split it in a way that would allow to have per-program contributors meetups on the Friday. The schedule would go as follows: Tuesday: cross-project workshops Wednesday, Thursday: traditional

Re: [openstack-dev] [all][TC][Zaqar] Another graduation attempt, new lessons learned

2014-09-17 Thread Eoghan Glynn
Thanks for bring this to the list, Flavio. A few thoughts in line ... Greetings, As probably many of you already know, Zaqar (formerly known as Marconi) has recently been evaluated for integration. This is the second time this project (and team) has gone through this process and just like

Re: [openstack-dev] [Ceilometer] Adding Nejc Saje to ceilometer-core

2014-09-19 Thread Eoghan Glynn
Hi, Nejc has been doing a great work and has been very helpful during the Juno cycle and his help is very valuable. I'd like to propose that we add Nejc Saje to the ceilometer-core group. Please, dear ceilometer-core members, reply with your votes! With eight yeas and zero nays, I

Re: [openstack-dev] [Ceilometer] Adding Dina Belova to ceilometer-core

2014-09-19 Thread Eoghan Glynn
Hi, Dina has been doing a great work and has been very helpful during the Juno cycle and her help is very valuable. She's been doing a lot of reviews and has been very active in our community. I'd like to propose that we add Dina Belova to the ceilometer-core group, as I'm convinced

Re: [openstack-dev] [Zaqar] Zaqar and SQS Properties of Distributed Queues

2014-09-19 Thread Eoghan Glynn
Hi All, My understanding of Zaqar is that it's like SQS. SQS uses distributed queues, which have a few unusual properties [0]: Message Order Amazon SQS makes a best effort to preserve order in messages, but due to the distributed nature of the queue, we cannot guarantee you will

[openstack-dev] [Ceilometer] PTL Candidacy

2014-09-23 Thread Eoghan Glynn
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

Re: [openstack-dev] [release] client release deadline - Sept 18th

2014-09-23 Thread Eoghan Glynn
The ceilometer team released python-ceilometerclient vesion 1.0.11 yesterday: https://pypi.python.org/pypi/python-ceilometerclient/1.0.11 Cheers, Eoghan Keystone team has released 0.11.1 of python-keystoneclient. Due to some delays getting things through the gate this took a few extra

Re: [openstack-dev] Feature freeze + Icehouse-3 milestone candidates available

2014-03-06 Thread Eoghan Glynn
Thanks Thierry, For completeness, the ceilometer links are below. tarball: http://tarballs.openstack.org/ceilometer/ceilometer-milestone-proposed.tar.gz milestone-proposed branch: https://github.com/openstack/ceilometer/tree/milestone-proposed Cheers, Eoghan - Original Message -

[openstack-dev] [ceilometer] nominating Ildikó Váncsa and Nadya Privalova to ceilometer-core

2014-03-10 Thread Eoghan Glynn
Folks, Time for some new blood on the ceilometer core team. I'd like to nominate Ildikó Váncsa and Nadya Privalova as ceilometer cores in recognition of their contributions([1], [2]) over the Icehouse cycle, and looking forward to their continued participation for Juno. Both showed up with

Re: [openstack-dev] [Ironic][Keystone] Move drivers credentials to Keystone

2014-03-25 Thread Eoghan Glynn
Hi, Right now Ironic is being responsible for storing the credentials for the IPMI and SSH drivers (and potentially other drivers in the future), I wonder if we should delegate this task to Keystone. The Keystone V3 API now has a /credentials endpoint which would allow us to specify

Re: [openstack-dev] [Ironic][Keystone] Move drivers credentials to Keystone

2014-03-26 Thread Eoghan Glynn
On 3/25/2014 1:50 PM, Matt Wagner wrote: This would argue to me that the easiest thing for Ceilometer might be to query us for IPMI stats, if the credential store is pluggable. Fetch these bare metal statistics doesn't seem too off-course for Ironic to me. The alternative is that

Re: [openstack-dev] [Ironic][Keystone] Move drivers credentials to Keystone

2014-03-26 Thread Eoghan Glynn
- Original Message - On 27 March 2014 06:28, Eoghan Glynn egl...@redhat.com wrote: On 3/25/2014 1:50 PM, Matt Wagner wrote: This would argue to me that the easiest thing for Ceilometer might be to query us for IPMI stats, if the credential store is pluggable. Fetch

Re: [openstack-dev] [Ironic][Keystone] Move drivers credentials to Keystone

2014-03-26 Thread Eoghan Glynn
Collins robe...@robertcollins.net wrote: On 27 March 2014 06:28, Eoghan Glynn egl...@redhat.com wrote: On 3/25/2014 1:50 PM, Matt Wagner wrote: This would argue to me that the easiest thing for Ceilometer might be to query us for IPMI stats, if the credential store

[openstack-dev] [Ceilometer] PTL Candidacy

2014-03-29 Thread Eoghan Glynn
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

Re: [openstack-dev] Ceilometer

2013-10-14 Thread Eoghan Glynn
Does your pipeline configuration file exist? (This defaults to /etc/ceilometer/pipeline.yaml, if not overridden via the pipeline_cfg_file config option.) - Original Message - Hi all, I tried to install openstack via devstack, while including ceilometer. The install of openstack is

Re: [openstack-dev] [neutron][ceilometer] Network Notification plugin broken. Ceilometer bug #1243292

2013-11-02 Thread Eoghan Glynn
Sphoorti, Just copying the list with some pointers on this issue that I gave you on IRC. Running 'neutron router-update' show that the tenant ID is absent from the 'router.update.start' but present in the 'router.update.end' notification. Note that the logic to send the update.start

Re: [openstack-dev] Horizon PTL candidacy

2013-11-12 Thread Eoghan Glynn
On 11/10/2013 11:53 PM, John Dickinson wrote: A random off-the-top-of-my-head use case would be to subscribe to events from creating or changing objects in a particular Swift account or container. This would allow much more efficient listings in Horizon for active containers (and may

Re: [openstack-dev] [Ceilometer][qa]Tempest tests for Ceilometer

2013-11-12 Thread Eoghan Glynn
Hello, guys! I hope everybody has eventually got home after the summit and feeling ok :) So it's time to proceed thinking about integration, unit and performance testing in Ceilometer. First of all I'd like to appreciate your help in composing etherpad

Re: [openstack-dev] [Ceilometer][qa] Tenant isolation - IntegrityError exception

2013-11-26 Thread Eoghan Glynn
Hi Nejc, Apologies for the delay in responding, I'm just getting to grips with Tempest myself. So the problem here is nothing to do with whether the tenant exists in keystone, in fact creating an alarm with a completely fictitious project_id will work just fine in general. Rather it appears to

Re: [openstack-dev] [ceilometer][qa] Punting ceilometer from whitelist

2013-12-03 Thread Eoghan Glynn
- Original Message - On 12/02/2013 10:24 AM, Julien Danjou wrote: On Fri, Nov 29 2013, David Kranz wrote: In preparing to fail builds with log errors I have been trying to make things easier for projects by maintaining a whitelist. But these bugs in ceilometer are coming in so

Re: [openstack-dev] [nova][ceilometer] FloatingIp pollster spamming n-api logs (bug 1328694)

2014-06-11 Thread Eoghan Glynn
Thanks for bringing this to the list Matt, comments inline ... tl;dr: some pervasive changes were made to nova to enable polling in ceilometer which broke some things and in my opinion shouldn't have been merged as a bug fix but rather should have been a blueprint. === The

Re: [openstack-dev] [nova][ceilometer] FloatingIp pollster spamming n-api logs (bug 1328694)

2014-06-14 Thread Eoghan Glynn
On 6/12/2014 10:31 AM, John Garbutt wrote: On 11 June 2014 20:07, Joe Gordon joe.gord...@gmail.com wrote: On Wed, Jun 11, 2014 at 11:38 AM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 6/11/2014 10:01 AM, Eoghan Glynn wrote: Thanks for bringing this to the list Matt, comments

Re: [openstack-dev] [nova][ceilometer] FloatingIp pollster spamming n-api logs (bug 1328694)

2014-06-14 Thread Eoghan Glynn
- Original Message - On 11 June 2014 20:07, Joe Gordon joe.gord...@gmail.com wrote: On Wed, Jun 11, 2014 at 11:38 AM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 6/11/2014 10:01 AM, Eoghan Glynn wrote: Thanks for bringing this to the list Matt, comments inline ... tl

Re: [openstack-dev] mysql/mysql-python license contamination into openstack?

2014-06-14 Thread Eoghan Glynn
On Thu Jun 12 14:13:05 2014, Chris Friesen wrote: Hi, I'm looking for the community viewpoint on whether there is any chance of license contamination between mysql and nova. I realize that lawyers would need to be involved for a proper ruling, but I'm curious about the view of the

[openstack-dev] An alternative approach to enforcing expected election behaviour

2014-06-16 Thread Eoghan Glynn
TL;DR: how about we adopt a soft enforcement model, relying on sound judgement and good faith within the community? Hi Folks, I'm concerned that the expected election behaviour review[1] is not converging on the optimal approach, partially due to the initial concentration on the

Re: [openstack-dev] [Ceilometer][Horizon] Exposing and showing associated resource_id within alarms/combined alarms

2014-06-16 Thread Eoghan Glynn
Hello guys, I was taking a look at the proposed alarm-page designs [1] for the bp: https://blueprints.launchpad.net/horizon/+spec/ceilometer-alarm-management-page and I saw that the alarms table has a column named “Resource Name”. The intention of that column is to show the resources

Re: [openstack-dev] An alternative approach to enforcing expected election behaviour

2014-06-16 Thread Eoghan Glynn
On Mon, 2014-06-16 at 10:56 +0100, Daniel P. Berrange wrote: On Mon, Jun 16, 2014 at 05:04:51AM -0400, Eoghan Glynn wrote: How about we rely instead on the values and attributes that actually make our community strong? Specifically: maturity, honesty, and a self-correcting nature

Re: [openstack-dev] [Horizon] [UX] Design for Alarming and Alarm Management

2014-06-16 Thread Eoghan Glynn
and will send a fresh link out when done. Anyone else with feedback, please feel free to fire away. Best, Liz On Jun 4, 2014, at 12:33 PM, Eoghan Glynn egl...@redhat.com wrote: Hi Liz, Two further thoughts occurred to me after hitting send on my previous mail. First

Re: [openstack-dev] [Horizon] [UX] Design for Alarming and Alarm Management

2014-06-16 Thread Eoghan Glynn
On Jun 16, 2014, at 10:56 AM, Eoghan Glynn egl...@redhat.com wrote: Apologies for the top-posting, but just wanted to call out some potential confusion that arose on the #os-ceilometer channel earlier today. TL;DR: the UI shouldn't assume a 1:1 mapping between alarms

[openstack-dev] [taskflow] Recommendations for the granularity of tasks and their stickiness to workers

2014-06-17 Thread Eoghan Glynn
Folks, A question for the taskflow ninjas. Any thoughts on best practice WRT $subject? Specifically I have in mind this ceilometer review[1] which adopts the approach of using very fine-grained tasks (at the level of an individual alarm evaluation) combined with short-term assignments to

Re: [openstack-dev] [taskflow] Recommendations for the granularity of tasks and their stickiness to workers

2014-06-17 Thread Eoghan Glynn
@lists.openstack.org Date: Tuesday, June 17, 2014 at 5:33 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [taskflow] Recommendations for the granularity of tasks and their stickiness to workers On 6/17/2014 7:04 AM, Eoghan

Re: [openstack-dev] An alternative approach to enforcing expected election behaviour

2014-06-18 Thread Eoghan Glynn
James E. Blair wrote: I think our recent experience has shown that the fundamental problem is that not all of the members of our community knew what kind of behavior we expected around elections. That's understandable -- we had hardly articulated it. I think the best solution to that

[openstack-dev] [swift] eventual consistency and lost updates

2014-06-27 Thread Eoghan Glynn
Hi Swiftsters! A basic question about swift eventual- versus strong-consistency. The context is potentially using swift as a store for metric data. Say datapoints {p1, p2, ..., p_i} are stored in a swift object. Presumably these data are replicated across the object ring in an eventually

Re: [openstack-dev] [ceilometer] Do we have IRC meeting this week?

2014-07-03 Thread Eoghan Glynn
Looks like many are in Paris midcycle meet-up. Do we have the weekly IRC meeting today? Hi Lianhao, We'll do a very short meeeting just to review juno-2 status, and remind folks about the upcoming spec deadlines for Juno. Shouldn't take more than a few minutes. Cheers, Eoghan

Re: [openstack-dev] [oslo] Asyncio and oslo.messaging

2014-07-06 Thread Eoghan Glynn
This is an attempt to summarize a really useful discussion that Victor, Flavio and I have been having today. At the bottom are some background links - basically what I have open in my browser right now thinking through all of this. Thanks for the detailed summary, it puts a more flesh on

Re: [openstack-dev] [Heat][Ceilometer] A proposal to enhance ceilometer alarm

2014-07-07 Thread Eoghan Glynn
In current Alarm implementation, Ceilometer will send back Heat an 'alarm' using the pre-signed URL (or other channel under development). By the other channel, do you mean the trusts-based interaction? We discussed this at the mid-cycle in Paris last week, and it turns out there appear to be

Re: [openstack-dev] [Heat][Ceilometer] A proposal to enhance ceilometer alarm

2014-07-07 Thread Eoghan Glynn
Alarms in ceilometer may currently only be based on a statistics trend crossing a threshold, and not on the occurrence of an event such as compute.instance.delete.end. Right. I realized this after spending some more time understanding the alarm-evaluator code. Having 'Statistics'

[openstack-dev] [qa][all] Branchless Tempest beyond pure-API tests, impact on backporting policy

2014-07-09 Thread Eoghan Glynn
TL;DR: branchless Tempest shouldn't impact on backporting policy, yet makes it difficult to test new features not discoverable via APIs Folks, At the project/release status meeting yesterday[1], I raised the issue that featureful backports to stable are beginning to show up[2], purely to

Re: [openstack-dev] [qa][all] Branchless Tempest beyond pure-API tests, impact on backporting policy

2014-07-09 Thread Eoghan Glynn
Thanks for the response Matt, some comments inline. At the project/release status meeting yesterday[1], I raised the issue that featureful backports to stable are beginning to show up[2], purely to facilitate branchless Tempest. We had a useful exchange of views on IRC but ran out of

Re: [openstack-dev] [qa][all] Branchless Tempest beyond pure-API tests, impact on backporting policy

2014-07-09 Thread Eoghan Glynn
tomorrow. I'll circle back with a more complete response after that. Cheers, Eoghan -Sean On 07/09/2014 05:41 AM, Eoghan Glynn wrote: TL;DR: branchless Tempest shouldn't impact on backporting policy, yet makes it difficult to test new features not discoverable via APIs

[openstack-dev] [all] Treating notifications as a contract

2014-07-10 Thread Eoghan Glynn
TL;DR: do we need to stabilize notifications behind a versioned and discoverable contract? Folks, One of the issues that has been raised in the recent discussions with the QA team about branchless Tempest relates to some legacy defects in the OpenStack notification system. Now, I don't

Re: [openstack-dev] [qa][all] Branchless Tempest beyond pure-API tests, impact on backporting policy

2014-07-10 Thread Eoghan Glynn
Note that the notifications that capture these resource state transitions are a long-standing mechanism in openstack that ceilometer has depended on from the very outset. I don't think it's realistic to envisage these interactions will be replaced by REST APIs any time soon. I wasn't

Re: [openstack-dev] [all] Treating notifications as a contract

2014-07-10 Thread Eoghan Glynn
Thanks for dusting this off. Versioning and published schemas for notifications are important to the StackTach team. It would be nice to get this resolved. We're happy to help out. Great! A great outcome would include some or all of the following: 1. more complete in-tree test

Re: [openstack-dev] [all] Treating notifications as a contract

2014-07-10 Thread Eoghan Glynn
It's not clear to me in this discussion what it is that is being versioned, contracted or standardized. Well the statement in the original mail was pretty explicit: versioned notification payloads to protect consumers from breaking changes in payload format So it's the standardization of

Re: [openstack-dev] [all] Treating notifications as a contract

2014-07-10 Thread Eoghan Glynn
One of the issues that has been raised in the recent discussions with the QA team about branchless Tempest relates to some legacy defects in the OpenStack notification system. Got links to specifics? I thought the consensus was that there was a contract here which we need to maintain,

Re: [openstack-dev] [all] Treating notifications as a contract

2014-07-10 Thread Eoghan Glynn
thinking discoverablity of the more downstream thing (the gathering of certain meters in ceilometer's case) would be far more meaningful to reason over. Cheers, Eoghan On Jul 10, 2014, at 2:48 AM, Eoghan Glynn egl...@redhat.com wrote: TL;DR: do we need to stabilize notifications behind

Re: [openstack-dev] [all] Treating notifications as a contract

2014-07-10 Thread Eoghan Glynn
The original implementation of the notification system was never intended to be the *final* implementation. I think we all identified the need for versioning several years ago. As for backwards compatibility, I think the version field itself, in whatever form it takes, should be optional. If

Re: [openstack-dev] [all] Treating notifications as a contract

2014-07-11 Thread Eoghan Glynn
tl;dr: Having a minimum payload standard enables more and more robust services on both sides of notification bus. Yes, that's exactly the point of this thread. We do not have a standard format for the payload. I think we should (more on that below). Again, such standardization is exactly

Re: [openstack-dev] [all] Treating notifications as a contract

2014-07-11 Thread Eoghan Glynn
But I guess you're suggesting not only that we version/schematize individual notification payloads, but that we do so in a way that's global across event types and emitters? That's partially correct. I'm suggesting the we consider standardizing a general format for notification

Re: [openstack-dev] [qa][all] Branchless Tempest beyond pure-API tests, impact on backporting policy

2014-07-12 Thread Eoghan Glynn
So I'm not sure that this should be a mandatory thing, but an opt-in. My real concern is the manpower, who is going to take the time to write all the test suites for all of the projects. I think it would be better to add that on-demand as the extra testing is required. That being said, I

Re: [openstack-dev] [all] Treating notifications as a contract

2014-07-14 Thread Eoghan Glynn
So what we need to figure out is how exactly this common structure can be accommodated without reverting back to what Sandy called the wild west in another post. I got the impression that wild west is what we've already got (within the payload)? Yeah, exactly, that was my

Re: [openstack-dev] Thoughts on the patch test failure rate and moving forward

2014-07-28 Thread Eoghan Glynn
Sean Dague wrote: To be clear, the functional tests will not be Tempest tests. This is a different class of testing, it's really another tox target that needs a devstack to run. A really good initial transition would be things like the CLI testing. Also, the Tempest team has gone out

Re: [openstack-dev] [ceilometer] [swift] Improving ceilometer.objectstore.swift_middleware

2014-07-31 Thread Eoghan Glynn
Swift is already emitting those numbers[1] in statsd format; could ceilometer consume those metrics and convert them to whatever notification format it uses? The problem with that approach, IIUC, is that the statsd metrics provide insufficient context. Ceilometer wants to meter usage on a

Re: [openstack-dev] [ceilometer] [swift] Improving ceilometer.objectstore.swift_middleware

2014-07-31 Thread Eoghan Glynn
As a curiosity, are there any ballpark numbers around the volume of notifications ceilometers can handle? Thinking about large scale swift deployments I expect to see thousands or even 10s of thousands of events per second. And that's with today's technology. Looking longer term I

Re: [openstack-dev] [ceilometer] Compute agent local VM inspector - potential enhancement

2014-08-01 Thread Eoghan Glynn
Disclaimer: I'm not fully vested on ceilometer internals, so bear with me. For consumers wanting to leverage ceilometer as a telemetry service atop non-OpenStack Clouds or infrastructure they don't own, some edge cases crop up. Most notably the consumer may not have access to the

Re: [openstack-dev] [ceilometer] Compute agent local VM inspector - potential enhancement

2014-08-01 Thread Eoghan Glynn
wrong :) Best regards! Kurt -邮件原件- 发件人: Eoghan Glynn [mailto:egl...@redhat.com] 发送时间: 2014年8月1日 14:46 收件人: OpenStack Development Mailing List (not for usage questions) 主题: Re: [openstack-dev] [ceilometer] Compute agent local VM inspector - potential enhancement

[openstack-dev] [tc][ceilometer] Some background on the gnocchi project

2014-08-06 Thread Eoghan Glynn
Folks, It's come to our attention that some key individuals are not fully up-to-date on gnocchi activities, so it being a good and healthy thing to ensure we're as communicative as possible about our roadmap, I've provided a high-level overview here of our thinking. This is intended as a

Re: [openstack-dev] [all] The future of the integrated release

2014-08-06 Thread Eoghan Glynn
Hi everyone, With the incredible growth of OpenStack, our development community is facing complex challenges. How we handle those might determine the ultimate success or failure of OpenStack. With this cycle we hit new limits in our processes, tools and cultural setup. This resulted in

Re: [openstack-dev] [Ceilometer] Approximate alarming

2014-04-28 Thread Eoghan Glynn
- Original Message - Hey everyone! I’d like to get your gut reaction on an idea for the future of alarming. Should I or should I not put it up for debate at the design summit? Hi Nejc, Yes this is certainly worthy of discussion at the design summit. Because the algorithms being

[openstack-dev] [ceilometer] cancelling team meeting for May 1st

2014-04-28 Thread Eoghan Glynn
Hi Folks, Since our French, Hungarian, Chinese, Russian and Slovenian contributors (geo-diversity WTF!) will all be celebrating International Workers' Day on May 1st, let's skip the weekly meeting. If anything pressing comes up, let's just have an emergent discussion to deal with it on

Re: [openstack-dev] [ceilometer] cancelling team meeting for May 1st

2014-04-28 Thread Eoghan Glynn
Hi Folks, Since our French, Hungarian, Chinese, Russian and Slovenian contributors (geo-diversity WTF!) will all be celebrating International Workers' Day A dyslexic moment: I meant geo-diversity FTW! :) on May 1st, let's skip the weekly meeting. If anything pressing comes up, let's

[openstack-dev] [Juno-Summit] availability of the project project pod rooms on Monday May 12th?

2014-04-29 Thread Eoghan Glynn
... the $subject says it all. Wondering about dedicated spaces for a cores meet-up prior to the design summit proper kicking off on the Tuesday. Thanks! Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [Juno-Summit] availability of the project project pod rooms on Monday May 12th?

2014-04-30 Thread Eoghan Glynn
IIRC Thierry said that pods will be available starting from Monday. Thanks Sergey, in the absence of any other indications to the contrary, I'm gonna assume that's the case :) Cheers, Eoghan On Tue, Apr 29, 2014 at 2:56 PM, Eoghan Glynn egl...@redhat.com wrote: ... the $subject says

Re: [openstack-dev] Monitoring as a Service

2014-05-07 Thread Eoghan Glynn
Hi Alexandre, I wanted to let this discussion develop a little before jumping in, as we've already had many circular debates about the cross-over between ceilometer and monitoring infrastructure in general. Personally I'm in favor of the big tent/broad church interpretation of ceilometer's

Re: [openstack-dev] Election Stats and Review Discussion

2014-05-24 Thread Eoghan Glynn
One of the things that OpenStack does really well is review our process for various activities. I don't believe we have had a discussion in the past reviewing our electoral process and I think it would be good to have this discussion. There are two issues that I feel need to be addressed:

[openstack-dev] [ceilometer] telemetry-specs repo renamed as ceilometer-specs

2014-05-24 Thread Eoghan Glynn
Hi Ceilometer folks, Just in case you weren't following the thread on *-specs repos being renamed from {project}-specs - {program}-specs[1] ... Note that there was a change of heart once the feedback from the community indicated some concerns about the discoverability of repos named for the

Re: [openstack-dev] [ceilometer] Unit Testing for Agents

2014-05-27 Thread Eoghan Glynn
- Original Message - Hello Stackers, Disclaimer: I'm on a quest to develop a new agent, already have coding a few lines. The next step is Unit Testing and enabling me to create a patch to test on a devstack. So, this is what brings me here, the need to understand and learn the

  1   2   >