| openstackgerrit | gordon chung proposed a change to openstack/ceilometer: Alembic migrations not tested https://review.openstack.org/71688 | 00:12 |
|---|---|---|
| *** thomasem has quit IRC | 00:15 | |
| openstackgerrit | gordon chung proposed a change to openstack/ceilometer: rename meter table to sample https://review.openstack.org/71691 | 00:18 |
| *** promulo has joined #openstack-ceilometer | 00:22 | |
| *** xmltok has quit IRC | 01:11 | |
| _cjones_ | Anyone know why I don't see any events on the ceilometer-collector. | 01:21 |
| *** promulo has quit IRC | 01:27 | |
| *** promulo has joined #openstack-ceilometer | 01:27 | |
| *** _cjones_ has quit IRC | 01:45 | |
| *** xianghui has joined #openstack-ceilometer | 02:13 | |
| openstackgerrit | Shuangtai Tian proposed a change to openstack/ceilometer: Use the module units to refer bytes type https://review.openstack.org/69269 | 02:42 |
| *** flwang has quit IRC | 03:00 | |
| *** flwang has joined #openstack-ceilometer | 03:04 | |
| *** promulo has quit IRC | 03:22 | |
| openstackgerrit | Dazhao Yu proposed a change to openstack/ceilometer: Make sure use IPv6 sockets for ceilometer in IPv6 environment https://review.openstack.org/67786 | 05:03 |
| *** xianghui has quit IRC | 05:13 | |
| *** xianghui has joined #openstack-ceilometer | 05:30 | |
| *** gordc has quit IRC | 05:39 | |
| *** sayali has joined #openstack-ceilometer | 05:50 | |
| *** ildikov_ has quit IRC | 05:54 | |
| *** _nadya_ has joined #openstack-ceilometer | 06:01 | |
| *** saju_m has joined #openstack-ceilometer | 06:03 | |
| openstackgerrit | Jenkins proposed a change to openstack/ceilometer: Imported Translations from Transifex https://review.openstack.org/62808 | 06:03 |
| openstackgerrit | Jia Dong proposed a change to openstack/ceilometer: Implement meter query by 'counter_volume' field https://review.openstack.org/67384 | 06:12 |
| *** jaypipes has quit IRC | 06:12 | |
| *** jaypipes has joined #openstack-ceilometer | 06:15 | |
| *** _nadya_ has quit IRC | 06:24 | |
| openstackgerrit | Zhang Jinnan proposed a change to openstack/ceilometer: Remove blank line in docstring https://review.openstack.org/72855 | 06:56 |
| *** eglynn has joined #openstack-ceilometer | 07:01 | |
| *** eglynn has quit IRC | 07:09 | |
| *** ildikov_ has joined #openstack-ceilometer | 07:14 | |
| *** eglynn has joined #openstack-ceilometer | 07:25 | |
| *** eglynn has quit IRC | 07:32 | |
| *** eglynn has joined #openstack-ceilometer | 07:47 | |
| *** eglynn has quit IRC | 08:07 | |
| *** julienvey_ has joined #openstack-ceilometer | 08:17 | |
| *** boris-42_ has joined #openstack-ceilometer | 08:30 | |
| *** eglynn has joined #openstack-ceilometer | 08:34 | |
| *** mihgen has joined #openstack-ceilometer | 09:02 | |
| *** yassine has joined #openstack-ceilometer | 09:18 | |
| *** flwang has quit IRC | 09:42 | |
| *** mihgen has quit IRC | 09:55 | |
| *** mihgen has joined #openstack-ceilometer | 10:02 | |
| eglynn | ildikov_: good morning! | 10:04 |
| ildikov_ | eglynn: good morning :) | 10:04 |
| ildikov_ | eglynn: is it a nice day for pipelines? | 10:04 |
| eglynn | hi, just a couple of quick thoughts on your project filtering in the pipeline idea | 10:04 |
| eglynn | ildikov_: ... not here in Dublin it's not! ;) | 10:05 |
| eglynn | ildikov_: ... back to our usual rain 24/7 | 10:05 |
| ildikov_ | eglynn:... I haven't seen the sun since I arrived back... | 10:05 |
| eglynn | ... /me digs for ML reference | 10:05 |
| eglynn | ... http://lists.openstack.org/pipermail/openstack-dev/2014-January/023683.html | 10:05 |
| ildikov_ | eglynn: yep, that's it | 10:06 |
| ildikov_ | eglynn: at the end we agreed on having a projects list in the pipeline config, like we have resources now | 10:06 |
| eglynn | ildikov_: yeah ... so some off-the-cuff ideas | 10:06 |
| eglynn | pulling back a little first to see the big picture | 10:07 |
| eglynn | ... there are two kinda separate cases here | 10:07 |
| eglynn | 1. notification handling | 10:07 |
| eglynn | 2. pollster polling | 10:07 |
| eglynn | in the case of #1, we can't AFAIK restrict which projects we get notified about | 10:08 |
| eglynn | so regardless of the pipeline config, we're gonna be told about all projects anyway | 10:08 |
| eglynn | so in that case, the filtering really is more like ... | 10:08 |
| eglynn | "throw the samples related to all but these projects on the floor" | 10:09 |
| eglynn | ... as opposed to ... | 10:09 |
| eglynn | "completely ignore projects not on this list" | 10:09 |
| eglynn | (we can't completely ignore as we get the notifications anyway) | 10:09 |
| ildikov_ | this filtering is more about specify project specific settings and for restricting projects from getting info | 10:09 |
| eglynn | so here's a wacky thought ... | 10:09 |
| eglynn | ... this kind of discarding of samples could easily be done as things stand in a simple transformer | 10:10 |
| eglynn | ... but just park that for a second | 10:10 |
| eglynn | then there's the case #2, actual polling | 10:11 |
| eglynn | here I'd imagine the goal is not to incurr the work of polling resources that relate to projects we're not interested in | 10:11 |
| eglynn | right? | 10:11 |
| eglynn | assuming that is so ... there are two sub-cases, I think | 10:12 |
| ildikov_ | how do you mean incur the work? | 10:12 |
| eglynn | ... well I mean ceilometer agents (compute, central etc.) not incurring the workload of say polling a resource belonged to a non-interesting project | 10:13 |
| ildikov_ | the whole idea here is to fine grain the piepline config, by making it possible to specify project specific settings | 10:13 |
| eglynn | yep | 10:13 |
| ildikov_ | ah, ok, yes | 10:13 |
| ildikov_ | so we could specify different polling inetrvals for instance | 10:14 |
| eglynn | sure, there's that | 10:14 |
| eglynn | or you could restrict to only metering certain projects | 10:14 |
| eglynn | and for others do no metering at all | 10:14 |
| eglynn | say an internal cloud is spun up by the engineering dept | 10:15 |
| ildikov_ | yes, it is a possibility too, but it is still the admin's choice as the config is still in pipeline.yaml | 10:15 |
| eglynn | engineers get un-billed access, but cloud is also shared with other departments, who are billed for their usage | 10:16 |
| eglynn | yeap, sure ... all driver by the admin's choices as expressed in the pipeline.yaml | 10:16 |
| eglynn | all *driven by | 10:16 |
| ildikov_ | yes, it's a good example for the non-metering | 10:16 |
| eglynn | k | 10:16 |
| eglynn | so, two two sub-cases for polling that I mentioned above | 10:17 |
| ildikov_ | and it also means to have less data in the DB | 10:17 |
| eglynn | 2.(a) polling REST APIs that don't allow easy constraint to a set of project IDs | 10:17 |
| eglynn | e.g. I don't think glance API allows you to say: | 10:17 |
| eglynn | "gimme all the image IDs that belong to projectA OR projectB OR projectC" in a single query | 10:18 |
| ildikov_ | hm, it's time to improve their query too ;) | 10:18 |
| eglynn | so in that case maybe easiest to create samples for *all* images and then just discard uninteresting samples in a transformer | 10:18 |
| ildikov_ | but it is still our choice that which data we will store in the db | 10:19 |
| eglynn | uninteresting == belonging to projects not on our list of project IDs | 10:19 |
| ildikov_ | yes, it's a vali option | 10:19 |
| ildikov_ | s/vali/valid/ | 10:19 |
| eglynn | sure ... I'm suggesting that transformers provide us an existing mechanism for doing the discard | 10:20 |
| eglynn | then the other sub-case of polling | 10:20 |
| eglynn | 2.(b) "two phase polling" ... i.e. resource discovery followed by per-resource polling | 10:20 |
| eglynn | example: compute agent discovers local instances first via nova-api, then polls the local hypervisor for each instance | 10:21 |
| eglynn | in that case you prolly wanna avoid the work of polling the hypervisor about instances owned by non-interesting projects, right? | 10:21 |
| ildikov_ | yes | 10:22 |
| eglynn | ... /me is thinking that avoidance could be done by chaining resource discovery extensions | 10:22 |
| eglynn | for context ... | 10:22 |
| eglynn | https://blueprints.launchpad.net/ceilometer/+spec/decoupled-source-sink-discoverable-resources | 10:22 |
| eglynn | introduces the idea of a resource discover extension | 10:22 |
| eglynn | e.g. the compute agent's call out to the nova-api will be encapsulated in a new "local_instances" extensions | 10:23 |
| eglynn | *extension, singular | 10:23 |
| eglynn | similarly for say disocvering baremetals via ironic API | 10:24 |
| eglynn | so what if these discovery extensions could be chained together? | 10:24 |
| eglynn | ... e.g. "local_instances" followed by "project_filter" | 10:25 |
| eglynn | ... the resources discovered by one extension would be fed into the next on the chain | 10:25 |
| eglynn | ... the next could add or subtract | 10:26 |
| eglynn | reason I got thinking along these lines was | 10:26 |
| eglynn | that it seemed project filtering could be done in a transformer in every other case | 10:27 |
| eglynn | apart from what I called 2(b) above | 10:27 |
| eglynn | well it could be done in 2(b) as well | 10:27 |
| eglynn | but only sub-optimally | 10:27 |
| ildikov_ | but if I would set the interval too, then it is not the transformer's business | 10:28 |
| ildikov_ | or I'm still missing somethnig from the big picture :) | 10:30 |
| eglynn | true, but I don't think setting the interval on a per-project basis really helps much in any case other than 2(b) | 10:30 |
| eglynn | so the interval is meaningless in the case of notifications, right? | 10:30 |
| eglynn | (... because we don't get to control when service emit notifications) | 10:30 |
| ildikov_ | in case of notifications yes | 10:31 |
| eglynn | sometimes that's driven by async lifecycle event | 10:31 |
| eglynn | sometimes by a cadence defined in the other service | 10:31 |
| ildikov_ | what about polling? | 10:31 |
| eglynn | yep, so in the polling case, /me was thinking 2(a) and 2(b) should considered separately | 10:32 |
| eglynn | in 2(a) it don't really help us much to only call out to glance for images owned by certain projects at a particular polling interval | 10:33 |
| eglynn | because the glance API will tell us about *all* images anyway | 10:33 |
| eglynn | so might as well just create samples for them all for every polling interval, then discard in the transform chains as necessary | 10:34 |
| eglynn | so it seems to me that only case 2(b) allows us to save any real work by restricting our attention to certain projects | 10:35 |
| ildikov_ | saving work is not the only benefit of the idea, I think :) | 10:35 |
| eglynn | yeah true | 10:37 |
| ildikov_ | Ceilometer have to deal with a large amount of data and if we do not store samples that are not needed, it can also be a benefit | 10:37 |
| *** flwang has joined #openstack-ceilometer | 10:37 | |
| eglynn | yeap, though discarding samples in a transformer would give that benefit also, right? | 10:38 |
| eglynn | ... i.e. the discard would happen in the originating agent | 10:38 |
| eglynn | ... central, compute, whatever | 10:38 |
| eglynn | ... before any samples are stored | 10:38 |
| ildikov_ | the interval also affects the amount of stored data | 10:38 |
| eglynn | not if the unneeded data is discarded before it stored? | 10:39 |
| eglynn | *it's | 10:39 |
| eglynn | similarly restrictive resource discovery would avoid the samples being created in the 1st place, so again not stored | 10:40 |
| ildikov_ | we can have projects, of which for instance the cpu util is not interesting in every 10 seconds, just in every two hours | 10:42 |
| ildikov_ | or cpu samples itself | 10:42 |
| eglynn | one sec | 10:43 |
| eglynn | ildikov_: ... sorry, back now | 10:45 |
| eglynn | so yeah, let's drill down into that example | 10:45 |
| eglynn | (projectA, projectB) => gimme cpu_util every 10s | 10:45 |
| eglynn | (projectX, projectY) => gimme cpu_util every 7200s | 10:46 |
| eglynn | so we need two pipelines | 10:46 |
| eglynn | one restricted to (projectA, projectB) with interval set to 10 | 10:46 |
| ildikov_ | yes, with the same transformer | 10:47 |
| eglynn | one restricted to (projectX, projectY) with interval set to 7200 | 10:47 |
| *** xianghui has quit IRC | 10:49 | |
| ildikov_ | so in your bp, we would need two sources, right? | 10:49 |
| eglynn | yep | 10:50 |
| eglynn | but let's stick to old unified (source+sink) pipeline for the second | 10:51 |
| ildikov_ | k | 10:51 |
| eglynn | ... just trying to think thru how the per-project filtering would work | 10:51 |
| eglynn | so we'd need to do the restriction somewhere in the pipeline, right? | 10:53 |
| eglynn | the question is, where in the current scheme would that make most sense to do? | 10:54 |
| ildikov_ | yes, I thought it before the transformers, but as you mentioned earlier, in some cases it could be done there | 10:54 |
| eglynn | so before the transformers, is also after the samples have been initially created by the pollsters | 10:54 |
| ildikov_ | but not in other case we could limit the polling itself | 10:55 |
| ildikov_ | if we do not have to fight for instance with the limitations of Glance API | 10:55 |
| eglynn | yep in the example of (projectX, projectY) we'd want to ensure that we don't hit the hypervisors for info about those instances every 10s | 10:55 |
| eglynn | when we're only gonna use that info every 7200s | 10:56 |
| ildikov_ | yep | 10:56 |
| eglynn | cool! | 10:56 |
| *** saju_m has quit IRC | 10:57 | |
| ildikov_ | so what's the next step from here? | 10:58 |
| eglynn | ok so consider how the compute agent currently works | 10:58 |
| eglynn | sorry /me was lost in a thought there for a sec! ;) | 10:59 |
| eglynn | so for each unique pipeline interval | 10:59 |
| eglynn | the compute agent sets up one of these puppies ... | 10:59 |
| ildikov_ | np, it happens to me too ;) | 10:59 |
| eglynn | https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/manager.py#L33 | 11:00 |
| eglynn | this task goes out and grabs *all* instances running on the local host | 11:00 |
| ildikov_ | do we have a chance to identify the instance-project relation there? | 11:01 |
| eglynn | and feeds each of these to each of the pollsters that match the meters filter on the pipeline in question | 11:01 |
| ildikov_ | can we make the puppy to know about which instance it should grab? | 11:01 |
| eglynn | yes, we could potentially check the 'projects' element of the pipeline within that outter for loop | 11:02 |
| eglynn | i.e. https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/manager.py#L36 | 11:02 |
| ildikov_ | ok | 11:03 |
| eglynn | well actually it's a tad messier that that /me thinks | 11:04 |
| eglynn | the task is not per-pipeline | 11:04 |
| ildikov_ | yes, I've just had a thought that it may not per-pipeline | 11:05 |
| eglynn | the task can have multiple pipelines, all added to the publish_context | 11:05 |
| eglynn | https://github.com/openstack/ceilometer/blob/master/ceilometer/agent.py#L52 | 11:05 |
| eglynn | so the task is really per-*interval* | 11:05 |
| eglynn | so we'd have to pick out the pipelines from the publish context that have a 'projects' element that matches the current instance and only publish samples on that | 11:07 |
| ildikov_ | you mean one task runs periodically? | 11:07 |
| eglynn | consider ... | 11:07 |
| eglynn | (projectA, projectB) => gimme cpu_util every 10s | 11:07 |
| eglynn | (projectX, projectY) => gimme cpu_util every 7200s | 11:07 |
| eglynn | (projectQ, projectR) => gimme cpu_util every 7200s | 11:07 |
| eglynn | then we'd have *two* polling tasks | 11:08 |
| eglynn | one for interval 10s (single pipeline) | 11:08 |
| eglynn | one for interval 7200s (two pipelines) | 11:08 |
| eglynn | each task runs periodically | 11:09 |
| eglynn | just a different period in each case | 11:09 |
| ildikov_ | yep | 11:09 |
| eglynn | so it seems like this logic might be a tad intrusive to the pollster manager | 11:11 |
| eglynn | to have to recognize which instances should be excluded in each case | 11:11 |
| eglynn | e.g. maintain multiple publish contexts with different non-disjoints subsets of the the pipeline in each case | 11:12 |
| eglynn | now fast-forward to i3 when we have sources and sinks decoupled in the pipeline config | 11:12 |
| eglynn | ... /me hopes! | 11:12 |
| ildikov_ | if that would help, than /me hope too ;) | 11:13 |
| eglynn | ... then the interval would be defined on just the source, not the entrire pipeline | 11:13 |
| eglynn | *entire | 11:13 |
| eglynn | BTW this per-project filtering is for Juno, right? | 11:14 |
| eglynn | (as opposed to i3) | 11:14 |
| ildikov_ | I wasn't from the beginning sure that the current solution will support the idea without any change | 11:14 |
| ildikov_ | yes, it is definitely for Juno | 11:14 |
| eglynn | meh! ... reading back /me realizes /me can't type | 11:15 |
| ildikov_ | we still have work and some waiting tasks with the complex query, so that definitely would be too much now | 11:15 |
| eglynn | I meant ... maintaining multiple publish_contexts each with a different non-disjoints subset of the set of pipelines with the same interval | 11:16 |
| ildikov_ | (I'm still a bit sad that Juno is not Jekyll...:) ) | 11:17 |
| ildikov_ | np, I more or less got, what you wanted to write there :) | 11:18 |
| eglynn | I was torn on Jekyll | 11:18 |
| eglynn | ... wasn't sure whether the tie in with Mr Hyde was a net positive | 11:19 |
| eglynn | http://en.wikipedia.org/wiki/Strange_Case_of_Dr_Jekyll_and_Mr_Hyde | 11:19 |
| eglynn | Mr. Hyde == AWS ? | 11:19 |
| eglynn | ;) | 11:19 |
| eglynn | ... anyhoo, back on topic | 11:19 |
| ildikov_ | :D | 11:20 |
| ildikov_ | anyway, my vote was on Jekyll :) | 11:20 |
| ildikov_ | BTW, I planned before your pipeline bp to figure out something for a better structure of pipeline def | 11:20 |
| ildikov_ | so we are at the point of figuring out what will be changed by the sources and sinks, right? | 11:22 |
| eglynn | yep | 11:22 |
| eglynn | so I'm thinking rather than having that complexity in the polling tasks | 11:22 |
| eglynn | (as described above) | 11:22 |
| eglynn | instead it's pushed into the resource discovery phase | 11:23 |
| eglynn | so we filter out those uninteresting resources before the sink does any work with them | 11:23 |
| eglynn | for polling sinks without explicit resource discovery | 11:23 |
| eglynn | or for notification-driven sinks | 11:24 |
| eglynn | we filter out in the transformer chain | 11:24 |
| ildikov_ | hm, will this solve the interval related didfficulties? | 11:25 |
| ildikov_ | and what do you mean here by transformer chain? | 11:26 |
| ildikov_ | the transformer section in each sink? | 11:26 |
| eglynn | well not in every sink | 11:26 |
| ildikov_ | sorry, I'm a bit lost :) | 11:27 |
| eglynn | ok, forget transformers for a sec | 11:27 |
| ildikov_ | not in every, but the ones in the sink definition part | 11:27 |
| *** mihgen has quit IRC | 11:27 | |
| ildikov_ | ok | 11:28 |
| eglynn | I think we could add a new abstraction in the source to simplify things | 11:28 |
| eglynn | in fact that would be much better from the source/sink separation PoV | 11:29 |
| ildikov_ | yes, I had a similar idea, when I saw your design | 11:29 |
| eglynn | cool | 11:29 |
| ildikov_ | but one bad news, is that I need to run first, to get my spine in shape again | 11:30 |
| eglynn | np! | 11:30 |
| *** ilyashakhat has joined #openstack-ceilometer | 11:30 | |
| ildikov_ | first=soon :) | 11:30 |
| eglynn | I'm up against the shot-clock too | 11:30 |
| eglynn | so let's park it there for the moment | 11:30 |
| eglynn | do you feel progress? | 11:30 |
| eglynn | that's forward progress | 11:31 |
| eglynn | as opposed to backward progress ;) | 11:31 |
| ildikov_ | it seemed to me that my idea is not impossible, even with your design | 11:31 |
| ildikov_ | I hope you agree :) | 11:32 |
| eglynn | right, certainly not impossible | 11:32 |
| eglynn | we just need to figure out where exactly to do the filtering | 11:32 |
| eglynn | and think thru a few typical cases | 11:32 |
| ildikov_ | and I think it would be usefull too, just needs more work to figure out how it should work exactly | 11:32 |
| eglynn | it's a bit clearer to me now, I think | 11:32 |
| ildikov_ | yes, definitely | 11:33 |
| eglynn | the discarding transformer idea was a blind alley I think | 11:33 |
| eglynn | so we need to work out a point in te source handling that allows filtering to occur | 11:33 |
| eglynn | in as generic a way as possible | 11:33 |
| ildikov_ | yes, this discussion helped me too | 11:33 |
| eglynn | yep, I think that's do-able | 11:33 |
| ildikov_ | yes, that's the next step in the process | 11:34 |
| eglynn | I'll keep it in mind as I dig into the source/sink impl over the next few days | 11:34 |
| ildikov_ | cool! :) | 11:34 |
| eglynn | let's aim to circle back on this before EoW | 11:34 |
| ildikov_ | that would be great, we can continue the discussion, if you will have some time and also, if you reach a point during the implementation that could be inetersting from this PoV | 11:35 |
| ildikov_ | ok, sounds good, tanks | 11:35 |
| ildikov_ | s/tanks/thanks/ | 11:35 |
| eglynn | I *hope* to have a WIP patch posted by EoW, that should help focus further discussion | 11:35 |
| eglynn | well thank you too, the discussion made it all clearer for me as well | 11:36 |
| ildikov_ | k, great :) | 11:36 |
| ildikov_ | it's good to hear that I not just wasted your time, with crazy ideas and stupid questions :) | 11:37 |
| eglynn | no its really good to tease these things out on IRC before much code is written | 11:38 |
| ildikov_ | yes, that's absolutely true, it makes coding life much easier in most of the cases :) | 11:38 |
| ildikov_ | k, I need to run now, I'll be super late again ;) | 11:39 |
| *** saju_m has joined #openstack-ceilometer | 11:40 | |
| ildikov_ | thanks again and then continue this week | 11:40 |
| ildikov_ | laters :) | 11:40 |
| *** ildikov_ is now known as ildikov_afk | 11:40 | |
| *** saju_m has quit IRC | 11:49 | |
| *** mihgen has joined #openstack-ceilometer | 11:55 | |
| *** julienvey_ has quit IRC | 11:58 | |
| *** julienvey_ has joined #openstack-ceilometer | 12:04 | |
| openstackgerrit | Balazs Gibizer proposed a change to openstack/ceilometer: Implements in operator for complex query functionality https://review.openstack.org/66687 | 12:09 |
| openstackgerrit | Balazs Gibizer proposed a change to openstack/ceilometer: Implements "not" operator for complex query https://review.openstack.org/66892 | 12:09 |
| openstackgerrit | Balazs Gibizer proposed a change to openstack/ceilometer: Implements metadata query for complex query feature https://review.openstack.org/66891 | 12:09 |
| openstackgerrit | Balazs Gibizer proposed a change to openstack/ceilometer: Implements field validation for complex query functionality https://review.openstack.org/65302 | 12:09 |
| *** julienvey_ has quit IRC | 12:09 | |
| *** julienvey_ has joined #openstack-ceilometer | 12:18 | |
| openstackgerrit | Balazs Gibizer proposed a change to openstack/ceilometer: Implements in operator for complex query functionality https://review.openstack.org/66687 | 12:19 |
| openstackgerrit | Balazs Gibizer proposed a change to openstack/ceilometer: Implements "not" operator for complex query https://review.openstack.org/66892 | 12:19 |
| openstackgerrit | Balazs Gibizer proposed a change to openstack/ceilometer: Implements metadata query for complex query feature https://review.openstack.org/66891 | 12:19 |
| openstackgerrit | Balazs Gibizer proposed a change to openstack/ceilometer: Implements field validation for complex query functionality https://review.openstack.org/65302 | 12:19 |
| *** eglynn has quit IRC | 12:33 | |
| *** promulo has joined #openstack-ceilometer | 12:40 | |
| *** Alexei_987 has joined #openstack-ceilometer | 12:45 | |
| *** sayali_ has joined #openstack-ceilometer | 12:47 | |
| *** sayali has quit IRC | 12:49 | |
| *** eglynn has joined #openstack-ceilometer | 12:58 | |
| *** saju_m has joined #openstack-ceilometer | 13:05 | |
| *** saju_m has quit IRC | 13:06 | |
| *** saju_m has joined #openstack-ceilometer | 13:07 | |
| *** jdob has joined #openstack-ceilometer | 13:28 | |
| *** prad_ has joined #openstack-ceilometer | 13:29 | |
| *** thomasem has joined #openstack-ceilometer | 13:31 | |
| *** thomasem_ has joined #openstack-ceilometer | 13:32 | |
| *** thomasem has quit IRC | 13:32 | |
| *** ildikov_afk is now known as ildikov_ | 13:34 | |
| ildikov_ | sileht: hi. are you around? | 13:34 |
| *** julienvey_ has quit IRC | 13:45 | |
| *** julienvey_ has joined #openstack-ceilometer | 13:47 | |
| *** saju_m has quit IRC | 14:21 | |
| *** mihgen has quit IRC | 14:27 | |
| *** tongli has joined #openstack-ceilometer | 14:27 | |
| tongli | @eglynn, ping. | 14:28 |
| eglynn | tongli: sup? | 14:28 |
| tongli | @eglynn, thanks so much for your comments. can you point me to the place where the alarm action takes place? | 14:28 |
| eglynn | tongli: https://github.com/openstack/ceilometer/blob/master/ceilometer/alarm/notifier/rest.py | 14:30 |
| tongli | @eglynn, the alarm_notifier agent actually does the alarm action? right? | 14:30 |
| eglynn | tongli: for webhooks ^^^ or for logging actions vvv | 14:30 |
| eglynn | https://github.com/openstack/ceilometer/blob/master/ceilometer/alarm/notifier/log.py | 14:30 |
| eglynn | tongli: yep https://github.com/openstack/ceilometer/blob/master/ceilometer/alarm/notifier/rest.py#L80 | 14:31 |
| tongli | @eglynn, they do not change the alarm state in anyway, even after the action has been performed? | 14:31 |
| eglynn | tongli: exactly, as I stated on gerrit | 14:32 |
| tongli | in that case, how does notifier know when to perform the action? and know if the action has been performed? | 14:32 |
| tongli | @eglynn, I think that is where I was lost. | 14:33 |
| eglynn | tongli: last comment on https://review.openstack.org/#/c/69473/11/ceilometer/alarm/evaluator/notification.py | 14:33 |
| eglynn | tongli: the evaluator tells the notifier to carry out the action via an RPC message | 14:33 |
| eglynn | tongli: the notifier is told the old state and the new state | 14:34 |
| tongli | ah. | 14:34 |
| eglynn | tongli: but the state transformation is not the notifier's concern | 14:34 |
| eglynn | tongli: that's the concern of the evaluator | 14:34 |
| tongli | evaluator does that. | 14:34 |
| *** gordc has joined #openstack-ceilometer | 14:34 | |
| tongli | ok. make sense. | 14:34 |
| tongli | @eglynn, now how will notification alarm maintain its state? | 14:35 |
| eglynn | tongli: one sec | 14:35 |
| tongli | @eglynn, see something, tell the notifier to take action, seems to me does not even need to update the state | 14:35 |
| tongli | @eglynn, I mean the evaluator monitors the notification, when conditions met, simply tell the notifier to take action, the alarm state does not even need to be persisted or updated. | 14:36 |
| eglynn | tongli: alarm action and alarm state are separate concepts | 14:37 |
| eglynn | tongli: the current alarm state is maintained persistently | 14:37 |
| eglynn | tongli: the action is a notification that the state has changed | 14:37 |
| tongli | @eglynn, yeah, what I mean is that seems to me that the notification alarm state does not even matter. | 14:38 |
| eglynn | tongli: no the state does matter, as the action includes information about the state | 14:38 |
| *** saju_m has joined #openstack-ceilometer | 14:38 | |
| eglynn | tongli: however the action is decoupled from the state transformation | 14:39 |
| eglynn | tongli: the fact that the action has occured *does not* mean that the state flips back | 14:39 |
| tongli | @eglynn, yeah, I got that , but what I am not clear about is how the state get changed from one to another. | 14:39 |
| tongli | @eglynn, especially in the notification alarm case. | 14:40 |
| *** jmckind has joined #openstack-ceilometer | 14:40 | |
| eglynn | tongli: as I said above, the alarm evaluator is responsible for detecting when state transitions occur | 14:40 |
| eglynn | tongli: in the case of the threshold alarm, it refers to the state as determined by the observed trend in the statistics | 14:41 |
| eglynn | tongli: ... outside threshold => state flips to ALARM | 14:41 |
| eglynn | tongli: ... inside threshold => state flips to OK | 14:41 |
| tongli | @eglynn, notification alarm is bit different, it is like for each notification comes in, evaluator knows if the condition is met or not. | 14:41 |
| eglynn | tongli: that's why I suggested in gerrit the idea of a time window | 14:41 |
| tongli | @eglynn, yeah, I got how threshold logic work. | 14:42 |
| eglynn | tongli: so the ALARM state does not mean "I saw this notification at some time in the past" | 14:42 |
| tongli | @eglynn, so you mean when the specified time elapsed, the state changed to OK. | 14:42 |
| eglynn | tongli: instead the ALARM state means "I saw this notification with the configured time window" | 14:42 |
| eglynn | *within the configured time window | 14:43 |
| eglynn | tongli: is that clear? | 14:43 |
| tongli | @eglynn, yeah, or even combined with threshold, like within specified windows, these many notifications. | 14:44 |
| eglynn | tongli: yeah, could be useful too | 14:44 |
| tongli | @eglynn, that is why I was thinking these should be sort of combined with threshold alarm. | 14:44 |
| eglynn | tongli: seems to me sufficiently different from threshold alarm | 14:45 |
| tongli | just with a time window? | 14:45 |
| eglynn | tongli: ... i.e. threshold alarm are oriented to statistics | 14:45 |
| eglynn | tongli: ... and periods | 14:45 |
| eglynn | tongli: whereas this refers to notifications over a time window | 14:45 |
| eglynn | tongli: vaguely similar, but still quite distinct | 14:45 |
| tongli | @eglynn, well, it could be over a time window (also period) with certain conditions (query). | 14:46 |
| eglynn | tongli: now a time window would point you back to the events API for the alarm evaluator | 14:46 |
| eglynn | tongli: instead of consuming the notifications as they arise | 14:46 |
| eglynn | tongli: otherwise you'd need to maintain a persistent timestamp as to when the notification was seen | 14:47 |
| tongli | @eglynn, yeah, true, | 14:47 |
| eglynn | tongli: ... otherwise wouldn't survive restarts | 14:47 |
| sileht | eglynn, tongli sorry but for me having alarm stuff in the ceilometer-notification-agent looks weirds, | 14:47 |
| eglynn | sileht: agree | 14:47 |
| tongli | @eglynn, the time window just means starting now, I will watch these notifications. | 14:47 |
| sileht | eglynn, tongli we don't know who is the owner of the notification at this step of the processing | 14:47 |
| eglynn | sileht: so I was suggesting using the events API instead of consuming notifications directly | 14:48 |
| sileht | eglynn, +1 | 14:48 |
| tongli | @sileht, I do not think I understand what you mean by "do not know who is the owner..." | 14:49 |
| *** mihgen has joined #openstack-ceilometer | 14:50 | |
| sileht | In ceilometer this is the role of a plugin.NotificationBase to parse a notification payload to retreive the user/project/resource id | 14:50 |
| tongli | @sileht, are we talking about same thing? | 14:51 |
| sileht | tongli, how do we ensure tenant X cannot trigger an alarm on a notificaiton owned by tenant Y | 14:52 |
| tongli | @sileht, it should be in the evaluator. | 14:53 |
| sileht | tongli, where is located the tenant_id in a notification ? that depends of the notification type | 14:54 |
| tongli | it becomes one of the condition. should the condition be any kind of the notification or the condition that requires match userid, ctenatn_id, etc. | 14:54 |
| tongli | u'_context_project_id': u'df58a6666d5440aca0582287494fde5a', u'_context_tenant_id': u'df58a6666d5440aca0582287494fde5a', u'_context_user': u'e532f7d9bdb341d0a4b41098d524743e', u'_context_user_id': u'e532f7d9bdb341d0a4b41098d524743e', | 14:54 |
| tongli | notice the information in the raw notification, | 14:55 |
| tongli | any of these can be used as condition to match it up. | 14:55 |
| tongli | it should not be limited to a specific tenant, or project or whatever. | 14:55 |
| tongli | the alarm definition should dictate that. | 14:56 |
| sileht | tongli, I don't think you can use the context for that | 14:57 |
| sileht | tongli, Imagine the case of a ReserllerAdmin do something on behalf an other user | 14:57 |
| sileht | the context have the RessellerAdmin ids, but the payload in the notification have the 'on behalf user' ids | 14:58 |
| tongli | @sileht, then in your alarm definition you define what kind of notification you would like to match up. | 14:59 |
| tongli | if you are looking for notification coming from that ResellerAdmin, then the notification should have some information of these. | 15:00 |
| sileht | tongli, sure | 15:00 |
| tongli | @sileht, if the raw notification does not have information, there is no way that the event can fabricate | 15:01 |
| tongli | @sileht going with the raw notification is a lot flexible, IMHO. | 15:02 |
| Alexei_987 | jd__: Hi what's the meeting agenda for today? | 15:02 |
| jd__ | Alexei_987: the one on the wiki page | 15:02 |
| Alexei_987 | jd__: it's seems that we have outdated agenda on the wiki | 15:02 |
| jd__ | let me check | 15:03 |
| jd__ | no that's our default agenda | 15:03 |
| Alexei_987 | jd__: I propose to add 1 topic https://review.openstack.org/#/c/72414/ | 15:03 |
| sileht | tongli, the raw notification have and all Notification plugin already have the code to parse some kind notification to extract this information | 15:03 |
| jd__ | Alexei_987: you think this is a worth a meeting? | 15:04 |
| Alexei_987 | jd__: I propose to discuss "I think that we should be ready to tolerate redundant data. Ceilometer is meant to be used at large scale and in such condition data redundancy is much better than low performance." | 15:04 |
| tongli | @sileht, yeah, the notification alarm simply takes the data and use it. Not do duplicate work. | 15:04 |
| Alexei_987 | jd__: and possible changes in data structure | 15:04 |
| Alexei_987 | jd__: but I guess it's better to be discussed on the summit | 15:05 |
| jd__ | Alexei_987: I'm having a hard time how this can be discussed in 20 minutes on IRC honestly | 15:05 |
| jd__ | yeah or a mailing list thread | 15:05 |
| Alexei_987 | jd__: agreed | 15:05 |
| sileht | tongli, I just want to be sure you are aware about 'Tenant Y' should not allowed to set alarm on 'Tenant X' notification (except if Tenant Y is a admin) | 15:05 |
| Alexei_987 | jd__: btw should I start publishing patches related to real backends stuff? | 15:06 |
| tongli | @jd__, can you shed some lights on how notification alarm state should be changed from one to another? | 15:06 |
| jd__ | Alexei_987: hm why do you even ask? :) | 15:06 |
| Alexei_987 | jd__: I still have some test failures :) | 15:06 |
| jd__ | tongli: not sure, likely sileht or eglynn might have a better idea than me | 15:06 |
| jd__ | Alexei_987: well you can still publish them and open bugs to track the issues that can be fixed in different patches | 15:06 |
| Alexei_987 | jd__: and I cannot make Postegres 100% working | 15:06 |
| Alexei_987 | jd__: ok I'll updload first series today | 15:07 |
| tongli | @jd__, ok, in that case, we go with the time window. | 15:07 |
| eglynn | tongli: my suggestion I made above ^^^ | 15:08 |
| tongli | @eglynn, yeah the time window, right? | 15:08 |
| eglynn | tongli: ... yeap, evaluated against the events API (as opposed to notifications directly consumed) | 15:09 |
| tongli | @eglynn, in that case, it will be part of the evaluator agent and loops forever? | 15:10 |
| tongli | @eglynn, lot of load on the api server. | 15:10 |
| tongli | @eglynn, I like the time window thing, but keep calling the event api (second hand) and add extra load for API servers, | 15:11 |
| tongli | @eglynn, I am not sure I like that. | 15:11 |
| eglynn | tongli: depends on how many notification alarms, how constrained their conditions are | 15:11 |
| tongli | @eglynn, true, but with raw notification,we do not have that problem. | 15:12 |
| eglynn | tongli: otherwise you'll have to remember received timestamps for the notifications somehow | 15:12 |
| eglynn | tongli: ... in a way that survives across restarts | 15:12 |
| *** eglynn is now known as eglynn-afk | 15:13 | |
| tongli | @eglynn, should we pay that much for it though. do not really know. | 15:15 |
| ildikov_ | sileht: will you have a few minutes for me? I have just one short question regarding to the sphinxcontrib-pecanwsme project. | 15:15 |
| sileht | ildikov_, sure | 15:15 |
| ildikov_ | sileht: thanks | 15:15 |
| ildikov_ | sileht: I have a fix for this project, which removes the trailing slash from the end of the URLs (webprefix) | 15:16 |
| ildikov_ | sileht: what is the way of proposing this fix to that project? | 15:16 |
| ildikov_ | sileht: contributing there was kind of out of scope for me until now | 15:17 |
| sileht | ildikov_, clone the repo on github, make your change and do a pull request | 15:18 |
| sileht | ildikov_, this lib is not yet in stackforge so, this is the old github way for this one | 15:18 |
| ildikov_ | sileht: ok, thanks | 15:19 |
| ildikov_ | sileht: what is the lifecycle of the project? | 15:19 |
| ildikov_ | sileht: I mean I need this fix for a Ceilometer bugfix | 15:19 |
| ildikov_ | sileht: if the fix is accepted, will this be available for Ceilometer too, or is there a release mechanism? | 15:20 |
| sileht | ildikov_, it depends on dhellmann_ , but in the past it have release a new version each time a pull request have been merged | 15:20 |
| ildikov_ | sileht: thanks very much, then I will follow the old github process and wait for response | 15:21 |
| *** mihgen has quit IRC | 15:22 | |
| openstackgerrit | A change was merged to openstack/ceilometer: Updated from global requirements https://review.openstack.org/71560 | 15:39 |
| openstackgerrit | Julien Danjou proposed a change to openstack/ceilometer: storage: store recording timestamp https://review.openstack.org/70166 | 15:43 |
| nprivalova | jd__, hi! Please approve https://review.openstack.org/#/c/68435/ . I'm afraid that I will be ought to rebase again and all votes disappear | 15:46 |
| jd__ | nprivalova: done | 15:47 |
| nprivalova | jd__, thanks! | 15:47 |
| *** prad_ has quit IRC | 15:49 | |
| *** sayali_ has quit IRC | 15:53 | |
| *** prad_ has joined #openstack-ceilometer | 15:56 | |
| *** jaypipes has quit IRC | 15:56 | |
| *** sayali_ has joined #openstack-ceilometer | 15:56 | |
| *** jaypipes has joined #openstack-ceilometer | 16:02 | |
| *** xmltok has joined #openstack-ceilometer | 16:14 | |
| *** dhellmann_ is now known as dhellmann | 16:17 | |
| dhellmann | gordc: ping | 16:24 |
| *** thomasem_ is now known as thomasem | 16:24 | |
| *** prad__ has joined #openstack-ceilometer | 16:26 | |
| *** prad_ has quit IRC | 16:28 | |
| dhellmann | gordc: https://bugs.launchpad.net/pycadf/+bug/1279405 | 16:29 |
| openstackgerrit | Alexei Kornienko proposed a change to openstack/ceilometer: Refactored fake connection URL classes https://review.openstack.org/72980 | 16:36 |
| gordc | dhellmann: thanks for the heads up. | 16:45 |
| gordc | dhellmann: i've approved dims patch so it should be merged in. | 16:46 |
| gordc | is that a gate test for Nova? | 16:47 |
| *** _cjones_ has joined #openstack-ceilometer | 16:51 | |
| dhellmann | gordc: I'm actually not sure | 16:57 |
| dhellmann | gordc: dims had a patch? fungi brought this up in #openstack-infra a bit ago | 16:58 |
| gordc | dhellmann: yeah. we rolled it back this morning: https://review.openstack.org/#/c/72949/ | 16:58 |
| dhellmann | gordc: ah | 16:58 |
| gordc | dhellmann: i'm assuming this fixes the issue. (it was the only change i checked in recently) | 16:59 |
| dhellmann | gordc: likely | 16:59 |
| gordc | dhellmann: i'll check with dims where that gate is being run. i assume all was ok since i didn't notice anything failing constantly. | 17:01 |
| dhellmann | gordc: ok, if that does fix the problem you can obviously close the bug :-) | 17:01 |
| *** thomasem_ has joined #openstack-ceilometer | 17:03 | |
| *** thomasem_ has quit IRC | 17:04 | |
| *** thomasem has quit IRC | 17:05 | |
| *** gordc has quit IRC | 17:48 | |
| *** _nadya_ has joined #openstack-ceilometer | 17:48 | |
| *** saju_m has quit IRC | 17:50 | |
| *** saju_m has joined #openstack-ceilometer | 17:51 | |
| *** ildikov_ has quit IRC | 17:53 | |
| *** saju_m has quit IRC | 17:58 | |
| *** saju_m has joined #openstack-ceilometer | 18:00 | |
| *** eglynn-afk has quit IRC | 18:07 | |
| *** ildikov_ has joined #openstack-ceilometer | 18:31 | |
| *** _nadya_ has quit IRC | 18:37 | |
| *** Alexei_987 has quit IRC | 18:49 | |
| *** saju_m has quit IRC | 18:51 | |
| *** _nadya_ has joined #openstack-ceilometer | 18:52 | |
| *** eglynn-afk has joined #openstack-ceilometer | 18:53 | |
| *** saju_m has joined #openstack-ceilometer | 19:01 | |
| *** julienvey_ has quit IRC | 19:03 | |
| _nadya_ | jd__, ping. or eglynn-afk | 19:05 |
| openstackgerrit | Jenkins proposed a change to openstack/ceilometer: Updated from global requirements https://review.openstack.org/73019 | 19:05 |
| *** eglynn-afk has quit IRC | 19:05 | |
| promulo | hey guys, did any of you ever enabled healthnmon on a devstack installation? | 19:17 |
| _nadya_ | I hope my message will not be lost. I cannot visit meeting today, so my update from tempest is the following | 19:22 |
| _nadya_ | We have good progress here https://review.openstack.org/#/c/70956/ . But notification tests cannot pass through Jenkins. It's very strange that dsvm-postgress-full pass but dsvm-full doesn't. I'm talking mostly about https://review.openstack.org/#/c/64136/ . If someone has comments about this please let me know. Or just share on meeting, I will read the logs | 19:22 |
| _nadya_ | lsmola: jd__, dhellmann, llu, sileht, ^^ | 19:25 |
| *** thomasem has joined #openstack-ceilometer | 19:27 | |
| *** _nadya_ has quit IRC | 19:45 | |
| *** eglynn-afk has joined #openstack-ceilometer | 19:47 | |
| *** saju_m has quit IRC | 19:48 | |
| *** julienvey_ has joined #openstack-ceilometer | 19:51 | |
| *** julienvey_ has quit IRC | 19:53 | |
| *** Alexei_987 has joined #openstack-ceilometer | 19:54 | |
| *** gordc has joined #openstack-ceilometer | 19:58 | |
| openstackgerrit | gordon chung proposed a change to openstack/ceilometer: sample table contains redundant/duplicate data https://review.openstack.org/65786 | 20:20 |
| openstackgerrit | gordon chung proposed a change to openstack/ceilometer: Alembic migrations not tested https://review.openstack.org/71688 | 20:20 |
| openstackgerrit | gordon chung proposed a change to openstack/ceilometer: rename meter table to sample https://review.openstack.org/71691 | 20:20 |
| *** eglynn-afk has quit IRC | 20:28 | |
| *** promulo has quit IRC | 20:33 | |
| *** eglynn-afk has joined #openstack-ceilometer | 20:33 | |
| *** boris-42_ has quit IRC | 20:55 | |
| *** jdob has quit IRC | 20:58 | |
| *** jdob has joined #openstack-ceilometer | 20:58 | |
| *** boris-42_ has joined #openstack-ceilometer | 20:59 | |
| *** thomasem has quit IRC | 21:01 | |
| *** eglynn-afk is now known as eglynn | 21:01 | |
| openstackgerrit | Alexei Kornienko proposed a change to openstack/ceilometer: Removed pecan app ref to fix test tearDown cleanup process https://review.openstack.org/73061 | 21:04 |
| openstackgerrit | Alexei Kornienko proposed a change to openstack/ceilometer: Fixed connection pooling in tests https://review.openstack.org/73062 | 21:04 |
| openstackgerrit | Alexei Kornienko proposed a change to openstack/ceilometer: * OSLO db.session fix https://review.openstack.org/73063 | 21:04 |
| openstackgerrit | Alexei Kornienko proposed a change to openstack/ceilometer: Run unit tests against MySQL https://review.openstack.org/59489 | 21:04 |
| *** jdob has quit IRC | 21:08 | |
| *** jdob has joined #openstack-ceilometer | 21:08 | |
| gordc | dhellmann: so this is related to notifier middleware which doesn't work in Nova anymore because of oslo.messaging upgrade. | 21:26 |
| jd__ | I saw that thread | 21:26 |
| gordc | dhellmann: when notifier middleware and audit middleware are graduated into oslo.notifier and oslo.middleware... how are they called from nova/neutron/? | 21:26 |
| jd__ | I think I'll work on porting it | 21:26 |
| jd__ | gordc: I don't think middleware is really going to be graduated as it is | 21:27 |
| jd__ | the notifier middleware should go in oslo.messaging IMHO | 21:27 |
| gordc | jd__: yeah, i wasn't sure what to do. i'm open to porting it over to oslo.messaging as well but not sure where to start. | 21:27 |
| jd__ | if it's not already there (I don't recall) | 21:27 |
| gordc | jd__: yep. i don't think it's there but dhellmann said it will be moved there. | 21:27 |
| jd__ | I'll try to do that | 21:28 |
| *** nealph_ has joined #openstack-ceilometer | 21:28 | |
| gordc | jd__: i was really just curious how the middleware would work after all this? do we still have audit middleware code replicated everywhere? | 21:28 |
| jd__ | gordc: not just importing in paste.ini the right egg/module and that should work | 21:29 |
| gordc | jd__: ...so if we pull out the code currently. to call notifier middlweare just add oslo.messaging.(middleware.)notifier to paste.ini and we're good? | 21:30 |
| jd__ | yes | 21:31 |
| gordc | jd__: and then the audit middleware would be... dhellmann said it would be moved to oslo.middleware lib but if not how would that work? | 21:31 |
| jd__ | dunnow | 21:31 |
| gordc | jd__: lol you gave me 50% of the answer :) | 21:33 |
| dhellmann | gordc: sorry, got distracted by a jenkins failure | 21:33 |
| *** eglynn has quit IRC | 21:33 | |
| gordc | dhellmann: hope it isn't my fault again. | 21:33 |
| *** nealph_ has quit IRC | 21:33 | |
| dhellmann | gordc: jd__ is right, the notifying middleware will go in oslo.messaging and the projects will import it from there instead of from their projects | 21:33 |
| dhellmann | gordc: no, one of my patches | 21:34 |
| gordc | dhellmann: cool cool. | 21:34 |
| *** nealph has joined #openstack-ceilometer | 21:34 | |
| gordc | dhellmann: so for audit middleware. if/when that goes to oslo.middleware. the projects would just need to add oslo.middlware to their requirements? | 21:34 |
| dhellmann | sileht: if ceilometer is blocked on an oslo review, please open a bug or blueprint for me so I can make sure it is on our review priority list | 21:35 |
| sileht | dhellmann, you mean ? https://blueprints.launchpad.net/oslo.messaging/+spec/notification-subscriber-server | 21:36 |
| dhellmann | gordc: I don't know the dependencies of that middleware off the top of my head, but probably | 21:36 |
| dhellmann | sileht: if that's the one, yes :-) | 21:36 |
| dhellmann | sileht: I was following up on the comment you made in the meeting while I looked away -- we have had other projects waiting for patches that we didn't know were blocking them | 21:36 |
| gordc | dhellmann: audit middleware just inherits notifier middleware right now...and overloads a few methods. | 21:36 |
| sileht | dhellmann, how I can make the link ? just a comment in the whtieboarD ? | 21:37 |
| dhellmann | sileht: that blueprint is already high and approved, so you've done what you need to -- I need to point it out to the oslo devs to encourage them to review the patches | 21:38 |
| sileht | dhellmann, ok cool :) | 21:38 |
| _cjones_ | Hey guys, quick question. I'm using ceilometer, Havana release with mongodb. Why do I not see any network.outgoing.packets in Horizon? | 21:40 |
| gordc | _cjones_: do you see incoming.packets? | 21:41 |
| _cjones_ | gordc: Negative, at least not in the gui. I see them in the db though. | 21:41 |
| _cjones_ | Those choices just seem abseent. So I'm wondering if it is just an oversight, or if I haven't configured something correctly. | 21:42 |
| *** promulo has joined #openstack-ceilometer | 21:42 | |
| gordc | _cjones_: i'd need to take a look at horizon code, i would think they'd grab the entire list of meters but maybe they're just picking some off selectively. | 21:43 |
| *** promulo has quit IRC | 21:43 | |
| *** promulo has joined #openstack-ceilometer | 21:43 | |
| _cjones_ | gordc: I suspect just a bug. No sense having you dig. I'll search and open one if need be. | 21:45 |
| gordc | _cjones_: ok, sure. have at it. | 21:46 |
| openstackgerrit | A change was merged to openstack/ceilometer: Adds additional details to alarm notifications https://review.openstack.org/70103 | 22:04 |
| openstackgerrit | Richard Su proposed a change to openstack/ceilometer: Add qpid-python to requirements.txt https://review.openstack.org/73083 | 22:22 |
| *** tongli has quit IRC | 22:29 | |
| *** jdob has quit IRC | 22:37 | |
| *** jmckind has quit IRC | 22:43 | |
| *** promulo has quit IRC | 22:50 | |
| *** promulo has joined #openstack-ceilometer | 22:50 | |
| openstackgerrit | Alexei Kornienko proposed a change to openstack/ceilometer: Fixed DateTime in PostgreSQL https://review.openstack.org/73092 | 23:00 |
| openstackgerrit | Alexei Kornienko proposed a change to openstack/ceilometer: Fix for get_statistics with postgresql https://review.openstack.org/59214 | 23:00 |
| openstackgerrit | Alexei Kornienko proposed a change to openstack/ceilometer: Run tests against PostgreSQL https://review.openstack.org/63049 | 23:00 |
| *** rwsu has quit IRC | 23:06 | |
| *** rwsu has joined #openstack-ceilometer | 23:08 | |
| _cjones_ | gordc: Are you around for another technical question? | 23:20 |
| gordc | _cjones_: i'll give it a try | 23:21 |
| _cjones_ | What is the virt_inspector. And why/how is that used. | 23:23 |
| gordc | _cjones_: this? https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/virt/inspector.py | 23:24 |
| _cjones_ | Ah, I think I got it. I was just looking at the base class. yes. | 23:24 |
| _cjones_ | It is just an inspector agent to retrieve information about the instances running in the virtual env. | 23:25 |
| _cjones_ | Or am I wrong? | 23:25 |
| gordc | yeah. it's used by our compute pollster. https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/manager.py#L73 | 23:25 |
| gordc | you'll see there it grabs a hypervisor inspector... depending on what you choose it'll use that inspector to gather metrics (libvirt by default) | 23:25 |
| _cjones_ | Right. I'm just trying to repurpose Horizon for a project and wanted to know where to put my code. | 23:25 |
| gordc | cool cool | 23:26 |
| _cjones_ | I thought I could get away with just writing my own pollsters, but it looks like it will be a bit more work. | 23:26 |
| _cjones_ | gordc Last one. You mentioned (libvirt by default), is there a setting in Ceilometer to change this? | 23:28 |
| gordc | yep | 23:30 |
| gordc | https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/virt/inspector.py#L32 | 23:30 |
| _cjones_ | Right. | 23:31 |
| gordc | basically in ceilometer.conf add hypervisor_inspector = hyperv option... it's the only other one (vmware is coming) | 23:31 |
| *** yassine has quit IRC | 23:41 | |
| openstackgerrit | Alexei Kornienko proposed a change to openstack/ceilometer: Fixed DateTime in PostgreSQL https://review.openstack.org/73092 | 23:42 |
| openstackgerrit | Alexei Kornienko proposed a change to openstack/ceilometer: Run unit tests against MySQL https://review.openstack.org/59489 | 23:42 |
| openstackgerrit | Alexei Kornienko proposed a change to openstack/ceilometer: Fix for get_statistics with postgresql https://review.openstack.org/59214 | 23:42 |
| openstackgerrit | Alexei Kornienko proposed a change to openstack/ceilometer: Fixed connection pooling in tests https://review.openstack.org/73062 | 23:42 |
| openstackgerrit | Alexei Kornienko proposed a change to openstack/ceilometer: * OSLO db.session fix https://review.openstack.org/73063 | 23:42 |
| openstackgerrit | Alexei Kornienko proposed a change to openstack/ceilometer: Run tests against PostgreSQL https://review.openstack.org/63049 | 23:42 |
| Alexei_987 | how can one find out version of mysqld that is used on jenkins? | 23:47 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!