| *** fnaval__ has joined #openstack-metering | 00:03 | |
| *** fnaval___ has joined #openstack-metering | 00:04 | |
| *** dina_belova has joined #openstack-metering | 00:04 | |
| *** fnaval_ has quit IRC | 00:05 | |
| *** fnaval__ has quit IRC | 00:07 | |
| *** fnaval___ has quit IRC | 00:08 | |
| *** dina_belova has quit IRC | 00:09 | |
| *** evanjfraser has joined #openstack-metering | 00:13 | |
| *** gordc has joined #openstack-metering | 00:15 | |
| *** zul has joined #openstack-metering | 00:36 | |
| *** gordc has quit IRC | 00:50 | |
| *** flwang has quit IRC | 00:52 | |
| *** dina_belova has joined #openstack-metering | 01:05 | |
| *** zul has quit IRC | 01:06 | |
| *** dina_belova has quit IRC | 01:10 | |
| *** sandywalsh has quit IRC | 01:27 | |
| *** sandywalsh has joined #openstack-metering | 01:45 | |
| openstackgerrit | A change was merged to openstack/ceilometer: Imported Translations from Transifex https://review.openstack.org/44216 | 01:53 |
|---|---|---|
| *** d34dh0r53 has joined #openstack-metering | 01:59 | |
| *** d34dh0r53 has quit IRC | 02:02 | |
| *** shaneduan is now known as shaneduan[afk] | 02:04 | |
| *** changbl has joined #openstack-metering | 02:05 | |
| *** dina_belova has joined #openstack-metering | 02:06 | |
| openstackgerrit | A change was merged to openstack/ceilometer: Adds Hyper-V compute inspector https://review.openstack.org/43709 | 02:08 |
| *** dina_belova has quit IRC | 02:10 | |
| *** flwang has joined #openstack-metering | 02:19 | |
| *** anteaya has quit IRC | 02:27 | |
| openstackgerrit | litong01 proposed a change to openstack/ceilometer: db2 implementation does not sort results of get_resources https://review.openstack.org/44390 | 02:31 |
| openstackgerrit | litong01 proposed a change to openstack/ceilometer: add tests for _query_to_kwargs func https://review.openstack.org/43796 | 02:31 |
| *** evanjfraser has quit IRC | 02:38 | |
| openstackgerrit | Lianhao Lu proposed a change to openstack/ceilometer: Added pollsters for the hardware agent https://review.openstack.org/43074 | 02:52 |
| openstackgerrit | Lianhao Lu proposed a change to openstack/ceilometer: Adding hardware-agent https://review.openstack.org/43072 | 02:52 |
| openstackgerrit | Lianhao Lu proposed a change to openstack/ceilometer: Added hardware agent's inspector and snmp implementation https://review.openstack.org/43073 | 02:52 |
| *** dina_belova has joined #openstack-metering | 03:06 | |
| *** dina_belova has quit IRC | 03:10 | |
| openstackgerrit | litong01 proposed a change to openstack/ceilometer: db2 implementation does not sort results of get_resources https://review.openstack.org/44390 | 03:23 |
| openstackgerrit | Fengqian.gao proposed a change to openstack/ceilometer: Add pagination support for sqlalchemy database https://review.openstack.org/35454 | 03:26 |
| openstackgerrit | Fengqian.gao proposed a change to openstack/ceilometer: Add pagination parameter to the database backends of storage https://review.openstack.org/42582 | 03:26 |
| openstackgerrit | Fengqian.gao proposed a change to openstack/ceilometer: Add pagination support to selected APIs https://review.openstack.org/37454 | 03:26 |
| openstackgerrit | Fengqian.gao proposed a change to openstack/ceilometer: Change pagination query method in mongodb https://review.openstack.org/41869 | 03:26 |
| openstackgerrit | Fengqian.gao proposed a change to openstack/ceilometer: Add a fake UUID to Meter database model named meter_id https://review.openstack.org/44278 | 03:26 |
| *** litong has quit IRC | 03:48 | |
| *** shang has joined #openstack-metering | 03:56 | |
| *** dina_belova has joined #openstack-metering | 04:07 | |
| *** fnaval_ has joined #openstack-metering | 04:08 | |
| *** fnaval_ has quit IRC | 04:09 | |
| *** fnaval_ has joined #openstack-metering | 04:10 | |
| *** shaneduan[afk] is now known as shaneduan | 04:11 | |
| *** dina_belova has quit IRC | 04:11 | |
| *** boris-42 has joined #openstack-metering | 04:46 | |
| *** SergeyLukjanov has joined #openstack-metering | 05:06 | |
| *** dina_belova has joined #openstack-metering | 05:07 | |
| *** dina_belova has quit IRC | 05:12 | |
| *** gordc has joined #openstack-metering | 05:19 | |
| *** SergeyLukjanov has quit IRC | 05:35 | |
| *** gordc has quit IRC | 05:43 | |
| *** dina_belova has joined #openstack-metering | 05:57 | |
| *** eglynn has joined #openstack-metering | 06:00 | |
| *** dina_belova has quit IRC | 06:01 | |
| *** dina_belova has joined #openstack-metering | 06:02 | |
| openstackgerrit | Jenkins proposed a change to openstack/ceilometer: Imported Translations from Transifex https://review.openstack.org/44405 | 06:04 |
| *** dina_belova has quit IRC | 06:06 | |
| *** shang has quit IRC | 06:06 | |
| *** shaneduan is now known as shaneduan[afk] | 06:26 | |
| *** SergeyLukjanov has joined #openstack-metering | 06:31 | |
| *** SergeyLukjanov has quit IRC | 06:33 | |
| *** tasdomas_afk is now known as tasdomas | 06:42 | |
| *** Bada has joined #openstack-metering | 06:45 | |
| *** Bada has quit IRC | 06:45 | |
| *** boris-42 has quit IRC | 06:49 | |
| openstackgerrit | A change was merged to openstack/ceilometer: Base Alarm history persistence model https://review.openstack.org/43848 | 06:54 |
| *** dina_belova has joined #openstack-metering | 06:58 | |
| *** shang has joined #openstack-metering | 07:01 | |
| *** yolanda has joined #openstack-metering | 07:08 | |
| *** dina_belova has quit IRC | 07:08 | |
| *** dina_belova has joined #openstack-metering | 07:09 | |
| openstackgerrit | A change was merged to openstack/ceilometer: Add pagination parameter to the database backends of storage https://review.openstack.org/42582 | 07:10 |
| *** shang has quit IRC | 07:11 | |
| *** dina_belova has quit IRC | 07:13 | |
| *** eglynn has quit IRC | 07:22 | |
| openstackgerrit | Lianhao Lu proposed a change to openstack/ceilometer: Added pollsters for the hardware agent https://review.openstack.org/43074 | 07:29 |
| *** shang has joined #openstack-metering | 07:29 | |
| *** janisg has joined #openstack-metering | 07:32 | |
| *** shang has quit IRC | 07:39 | |
| *** shang has joined #openstack-metering | 07:39 | |
| *** shaneduan[afk] is now known as shaneduan | 07:56 | |
| *** eglynn has joined #openstack-metering | 08:06 | |
| *** shaneduan is now known as shaneduan[afk] | 08:10 | |
| *** Alexei_987 has joined #openstack-metering | 08:13 | |
| *** dina_belova has joined #openstack-metering | 08:20 | |
| *** dina_belova has quit IRC | 08:24 | |
| *** Fengqian has joined #openstack-metering | 08:28 | |
| *** Fengqian has quit IRC | 08:33 | |
| *** Fengqian has joined #openstack-metering | 08:35 | |
| *** Fengqian has quit IRC | 08:47 | |
| openstackgerrit | A change was merged to openstack/ceilometer: Extra indexes cleanup https://review.openstack.org/42716 | 08:48 |
| *** Fengqian has joined #openstack-metering | 08:57 | |
| Fengqian | hello | 08:57 |
| Fengqian | i have two questions about ceiolmeter pagination-query bp. One is the sort key of get_meters and another is get_resources of mongoDB | 08:58 |
| Fengqian | https://review.openstack.org/#/c/44278/ | 08:59 |
| Fengqian | A fake UUID for Meter, actually the combination of resource_id and counter_name, is it make sense here? | 09:00 |
| *** dina_belova has joined #openstack-metering | 09:20 | |
| *** dina_belova has quit IRC | 09:25 | |
| jd__ | hey Fengqian | 09:29 |
| jd__ | a lot of ping timeout :) | 09:30 |
| jd__ | <jd__> if you want a unique id, message_id is a unique id [10:44] | 09:30 |
| jd__ | <jd__> so what your code is doing is useless | 09:30 |
| jd__ | <jd__> that's the first point | 09:30 |
| jd__ | a unique field is needed for pagination of samples | 09:30 |
| jd__ | for the pagination of meters, there's no table with meters, the meter table stores _samples_ not meters (meters are the counter_name field basically) | 09:30 |
| Fengqian | if we use message_id, how can users get this value from API level, when they using get_meters? | 09:32 |
| Fengqian | The model of Meter does not have message_id, right? | 09:32 |
| jd__ | Fengqian: it wouldn't make sense | 09:39 |
| jd__ | you have to build a unique value based on the fields present in the Meter model in the API | 09:40 |
| jd__ | probably in the API, not in the storage driver | 09:40 |
| jd__ | and split it to values you can paginate on in he API, and passes it on the storage drivers | 09:40 |
| *** boris-42 has joined #openstack-metering | 09:45 | |
| jd__ | Fengqian: do I make sense? | 09:47 |
| Fengqian | yes, it is not the best solution that use resource_id + counter_name:). But how can we do if we do not want to change database schema? | 09:49 |
| jd__ | Fengqian: you can compoute that dynamically no? | 09:50 |
| jd__ | I don't why you need to _store_ it | 09:50 |
| Fengqian | yes, we surely can compute it. The reason i store it because i think the user may need this value from API level if they do not want to compute it | 09:52 |
| Fengqian | otherwise, user have to compute it and pass in the value | 09:52 |
| llu | jd__, I think we can dynamically compute 'resource_id + counter_name' for meter, but not message_id, message_id is only for sample, agreed? | 09:53 |
| Fengqian | yes, message_id is only for sample | 09:54 |
| *** flwang has quit IRC | 09:54 | |
| Fengqian | dynamically compute 'resource_id + counter_name', i think that means we will add the compute part in API level, right? | 09:56 |
| Fengqian | i mean, if user do not compute that, we must do that part | 09:56 |
| llu | Fengqian, user should never do the computing, the meter_id is opaque to them | 09:57 |
| Fengqian | sure:) i mean when GET/meters/limit=1?marker_value=****** | 09:58 |
| *** shaneduan[afk] is now known as shaneduan | 10:01 | |
| jd__ | llu: agreed | 10:03 |
| jd__ | Fengqian: yes compute in the API part, that was my point | 10:03 |
| *** fnaval_ has quit IRC | 10:05 | |
| *** fnaval_ has joined #openstack-metering | 10:06 | |
| Fengqian | ok, got it | 10:06 |
| llu | jd__: one more thought about the pagination API. Do we want to expose the whole feature(marker/limit/sort_keys/sort_dirs) to the API user? | 10:09 |
| llu | or we just follow other openstack servier only expose (marker/limit) to the API user. | 10:09 |
| *** fnaval_ has quit IRC | 10:10 | |
| *** shaneduan is now known as shaneduan[afk] | 10:10 | |
| llu | exposing the full featured pagination seems make the restful API complicated. | 10:11 |
| jd__ | llu: I'd think expose everything | 10:11 |
| jd__ | llu: it's _options_ | 10:11 |
| jd__ | :-) | 10:11 |
| llu | jd__: ok | 10:12 |
| *** Fengqian has quit IRC | 10:20 | |
| openstackgerrit | A change was merged to openstack/ceilometer: Fix wrong UniqueConstraint name https://review.openstack.org/42715 | 10:21 |
| *** dina_belova has joined #openstack-metering | 10:21 | |
| jd__ | sileht: do you have an ongoing patch on the mongodb connection problem? | 10:22 |
| sileht | jd__, I have made some test with only netloc for the connection pool of mongo, it seems mongoclient create a new connection each time you request a db different than the one used at the creation of the MongoClient object | 10:23 |
| jd__ | facepalm | 10:23 |
| *** boris-42 has quit IRC | 10:24 | |
| *** dina_belova has quit IRC | 10:26 | |
| sileht | jd__, I have read that in pymongo doc: 'applications in which more than 100 threads are in requests at once should disable the max_pool_size option' | 10:26 |
| jd__ | yeah but we don't use the pool | 10:26 |
| jd__ | (I think) | 10:26 |
| sileht | jd__, we use it | 10:26 |
| jd__ | that's why we have our own pool | 10:27 |
| jd__ | if we use it, it doesn't work then :-) | 10:28 |
| sileht | jd__, \o/ | 10:31 |
| sileht | jd__, I have added max_pool_size=None and put maxConns=32 and it seems to work now | 10:32 |
| sileht | jd__, does this fix seem resonnable ? | 10:34 |
| *** llu is now known as llu_away | 10:44 | |
| *** shang has quit IRC | 10:44 | |
| sileht | jd__, max_pool_size=None workaround the problem but ~23000 connections are opened (and never closed) by pymongo | 10:55 |
| * sileht out for lunch | 10:56 | |
| *** flwang has joined #openstack-metering | 10:59 | |
| *** shaneduan[afk] is now known as shaneduan | 11:02 | |
| *** shaneduan is now known as shaneduan[afk] | 11:11 | |
| *** dina_belova has joined #openstack-metering | 11:21 | |
| *** dina_belova has quit IRC | 11:26 | |
| *** boris-42 has joined #openstack-metering | 11:37 | |
| *** boris-42 has quit IRC | 11:40 | |
| jd__ | sileht: how can you have 23k open connections with maxConns=32? | 11:52 |
| sileht | jd__, 42 | 11:53 |
| jd__ | okay | 11:53 |
| sileht | jd__, it seems to be only TIME_WAIT connection ... | 11:55 |
| jd__ | fair enough | 11:55 |
| *** thomasm has joined #openstack-metering | 12:01 | |
| thomasm | hey all! | 12:03 |
| sileht | jd__, do you think we must change max_pool_size=None for test only or not ? | 12:05 |
| jd__ | sileht: I don't now yet, I'm reading pymongo | 12:06 |
| sileht | jd__, I suspected something with the thread handling of pymongo and eventlet | 12:08 |
| jd__ | sileht: we had to remove use_greenlet=True recently | 12:08 |
| *** yolanda has quit IRC | 12:09 | |
| sileht | jd__, yes to let pymongo use the monkey patched threading module | 12:10 |
| *** dina_belova has joined #openstack-metering | 12:22 | |
| *** dina_belova has quit IRC | 12:27 | |
| swann | hi sileht, jd__ : We can ask Linux to recycle more quickly connections (in TIME_WAIT) by setting the sysctl param : net.ipv4.tcp_tw_recycle=1 | 12:38 |
| swann | if can help .. | 12:39 |
| swann | obviously, it's not resolve problem if it's connection leak. | 12:39 |
| jd__ | swann: yeah, this isn't going to help much as we're not goint to be root to run the test suite :-) | 12:40 |
| swann | jd__: understandable | 12:41 |
| *** boris-42 has joined #openstack-metering | 12:43 | |
| *** anteaya has joined #openstack-metering | 12:50 | |
| *** gordc has joined #openstack-metering | 12:52 | |
| *** bpokorny has joined #openstack-metering | 12:55 | |
| annegentle_ | go go go jd__ | 12:57 |
| annegentle_ | :) | 12:57 |
| jd__ | hey annegentle_ ! | 12:59 |
| jd__ | did you see my question on -infra and do they make sense to you? | 12:59 |
| annegentle_ | jd__: reading there too | 12:59 |
| *** shaneduan[afk] is now known as shaneduan | 13:02 | |
| *** shaneduan is now known as shaneduan[afk] | 13:11 | |
| *** cflma has joined #openstack-metering | 13:14 | |
| *** cflma has quit IRC | 13:15 | |
| *** sandywalsh_ has joined #openstack-metering | 13:20 | |
| swann | sileht, eglynn : Hi to you, I've may be an issue concerning the alarm with autoscaling stuff, I would like your feedback. | 13:22 |
| *** dina_belova has joined #openstack-metering | 13:22 | |
| eglynn | swann: what's the problem? | 13:23 |
| swann | I opened a bug for Heat https://bugs.launchpad.net/heat/+bug/1215840 and I pushed a patch https://review.openstack.org/#/c/43698/4 (not yet? aprouved) | 13:23 |
| * eglynn looking | 13:23 | |
| swann | with this patch the ceilometer-alarm-singleton can't evaluate the alarm, more precisly this is the API which return a 400 HTTPBadRequest on the statistic query. | 13:23 |
| *** sandywalsh has quit IRC | 13:24 | |
| swann | http://paste.openstack.org/show/45465/ | 13:24 |
| *** dina_belova has quit IRC | 13:27 | |
| eglynn | swann: one sec, I'll take a look ... | 13:28 |
| swann | eglynn: I've time :) | 13:28 |
| *** flwang has quit IRC | 13:28 | |
| swann | eglynn: basiclly, I add the stackId in alarm rules and it seems the API don't like caractere like ':' or it's the alarm-evaluator which build a bad query | 13:32 |
| eglynn | swann: one sec, just finishing up something else | 13:32 |
| *** litong has joined #openstack-metering | 13:39 | |
| *** flwang has joined #openstack-metering | 13:42 | |
| openstackgerrit | Julien Danjou proposed a change to openstack/ceilometer: doc: fix storage backend features status https://review.openstack.org/44453 | 13:47 |
| *** shaneduan[afk] is now known as shaneduan | 13:47 | |
| *** boris-42 has quit IRC | 13:48 | |
| *** anteaya is now known as ColinMochrie | 13:50 | |
| eglynn | check first in mongo | 14:02 |
| eglynn | $ mongo ceilometer | 14:02 |
| eglynn | > db.meter.find({'counter_name': 'image.download'}) | 14:03 |
| eglynn | (for example) | 14:03 |
| eglynn | sorry wrong channel for the above ^^^ | 14:04 |
| eglynn | please ignore | 14:05 |
| litong | @thomasm, ping | 14:14 |
| thomasm | litong, hello! | 14:14 |
| litong | please see this patchset. https://review.openstack.org/#/c/44390/ | 14:14 |
| litong | I realize that with current code, I can not add the sort because the sort | 14:15 |
| thomasm | litong, I just commented there. So, with the sort key set up, I can aggregate like in the mongo driver, correct? | 14:15 |
| thomasm | litong, oh? | 14:15 |
| litong | because the latest code does not have sort_key and sort_dir in yet. | 14:15 |
| litong | with what I added in that patchset, you can add these code I put out in your patchset. | 14:16 |
| litong | so they can go together. | 14:16 |
| litong | @thomasm, making sense? | 14:16 |
| litong | @thomasm, u there? | 14:18 |
| thomasm | litong, yeah, sorry reading the patch | 14:19 |
| thomasm | litong, So, I'm not sure I understand why we're checking for mongo in a db2 driver? | 14:19 |
| litong | @thomasm, actually the change will support sort. | 14:19 |
| litong | @thomasm, because of jenkins. | 14:19 |
| litong | we do not have db2 on jenkins, so when test db2 driver, I use mongdo. | 14:20 |
| litong | @thomasm, that is the reason. If we never wanted to test db2 driver on jenkins, these code go away. | 14:20 |
| thomasm | litong, So, this is just a temporary work around? | 14:20 |
| litong | @thomasm, as long as we do not have db2 on jenkins and we want to test the db2 driver, these code need to be in. | 14:21 |
| thomasm | litong, Oh, okay | 14:21 |
| litong | @thomasm, this also is a work around for developers, and I bet not many of them has db2 on their machine. | 14:22 |
| litong | so these work around are important. | 14:22 |
| thomasm | litong, What's confusing me is I see it implementing the sort keys for DB2 but not for mongo? | 14:23 |
| *** dina_belova has joined #openstack-metering | 14:23 | |
| litong | @thomasm, ? | 14:24 |
| *** ColinMochrie is now known as anteaya | 14:25 | |
| thomasm | litong, I posted a comment on the line: https://review.openstack.org/#/c/44390/ | 14:25 |
| litong | @thomasm, see the comments. we do not need sort when we get the resource ids from meter collection. | 14:28 |
| *** dina_belova has quit IRC | 14:28 | |
| *** shaneduan is now known as shaneduan[afk] | 14:28 | |
| litong | @thomasm, the sort is done when query resource collection. | 14:28 |
| *** SergeyLukjanov has joined #openstack-metering | 14:29 | |
| thomasm | litong, Oh, I'm sorry - I misunderstood. :) | 14:29 |
| *** alexb_ has quit IRC | 14:29 | |
| thomasm | litong, I see it now, heh. Thought that sort was a part of the query above. Eyes tricked me. | 14:29 |
| litong | @thomasm, yeah. the other reason I can not use the code for mongodb is that db2 has some limited aggreagte functions. | 14:30 |
| litong | @thomasm, for example, it does not have $first, $push, $addToSet implemented. | 14:30 |
| thomasm | litong, That's concerning. Reason being, we need those to grab min/max and latest representation from the samples. | 14:31 |
| litong | @thomasm, so that the aggregate method can not be used, so I have to keep the original logic. | 14:31 |
| thomasm | Because the resource collection has no concept of time, we need to use samples in order to filter latest representation within a time limit. | 14:31 |
| thomasm | litong, Or, at the very least, add timestamp to the resource collection for last updated since messages can be out of order and we don't want to overwrite a newer state with an older one. | 14:32 |
| eglynn | swann: sorry, just getting back to this now | 14:32 |
| litong | @thomasm, changing schema right now is probably not a good idea. | 14:32 |
| eglynn | swann: k, so the problem is that the ceilo API service uses ast.literal_eval to interpret the qury parameters | 14:33 |
| litong | @thomasm, that will also causing changes to migration, I do not know if you want to do that now. | 14:33 |
| eglynn | swann: when you use a colon in the user metadata value, this confuses the AST | 14:33 |
| thomasm | litong, Yeah, so I guess we'll have to do the aggregation manually, then? | 14:34 |
| thomasm | in the Python | 14:34 |
| eglynn | swann: (... as it's expecting that to have a certain meaning, e.g. as key:value separator in a dict definition) | 14:34 |
| litong | @thomasm, that is where the code and logic will differ for mongodb and db2. | 14:35 |
| eglynn | swann: so it's not an issue per se with the alarming logic | 14:35 |
| eglynn | swann: more just an undocumented restriction on queryable user metadata | 14:35 |
| eglynn | swann: (within the API service) | 14:35 |
| thomasm | litong, Gotcha. Alright, so I can at least get the timestamp sorted data back. Thanks. Let me pull this down and see what I can do with it. =] | 14:36 |
| eglynn | swann: was there a particular reason that you needed the colon in the user metadata value? | 14:36 |
| litong | @thomasm, since the sort_key, sort_dir are not in yet, I can not really make these changes. | 14:36 |
| litong | I will here and let me know what I can do to help. | 14:37 |
| litong | as far as the sort goes, the code and logic are in that patch and I've tested last night, they all work against both mongdb and db2. | 14:37 |
| *** tasdomas is now known as tasdomas_afk | 14:39 | |
| *** boris-42 has joined #openstack-metering | 14:40 | |
| thomasm | litong, Where do sort_key and sort_dir need to be added? | 14:40 |
| eglynn | swann: did that make sense? | 14:41 |
| litong | @thomasm, I thought you are adding these parameters to get_resources and get_meters method. | 14:41 |
| litong | @thomasm, the latest code in upstream does not have these in the method signature. | 14:42 |
| swann | eglynn: I understand the limitation of the api even I don't know what is AST .. | 14:43 |
| thomasm | litong, No, I'm just correcting the drivers to return the latest resource representation - that's the bug I'm fixing. -- https://bugs.launchpad.net/ceilometer/+bug/1208547 | 14:43 |
| eglynn | swann: AST = "Abstract Syntax Tree" | 14:43 |
| eglynn | swann: http://docs.python.org/2/library/ast.html | 14:43 |
| swann | eglynn: the colon come from the stackId which is generated by Heat | 14:43 |
| eglynn | swann: can you sanitize this? | 14:44 |
| eglynn | swann: e.g. map ':' to '_' | 14:44 |
| thomasm | litong, So, whenever somebody calls the function it needs to return the latest resource_metadata according to the timestamp. It was originally just undefined behavior based on how the driver handled grabbing non-aggregated samples from an aggregated query. | 14:44 |
| *** sandywalsh_ has quit IRC | 14:44 | |
| thomasm | litong, This also means being able to do that within a start/end time period so people can get resource representation for a previous period of time. | 14:45 |
| swann | eglynn: don't know, I have to talk with heat guys if it's acceptable for them | 14:45 |
| eglynn | swann: k | 14:45 |
| litong | @thomasm, so get_resources and get_meters will have to sort regardless. | 14:45 |
| litong | the sort keys will have to be what? | 14:46 |
| thomasm | litong, timestamp, and their sample ID to tie-break. | 14:46 |
| thomasm | litong, Not sure if we want to sort on anything else. | 14:47 |
| litong | @thomasm, the sample ID is just the _id, right? | 14:47 |
| litong | @thomasm, why do you want to sort on that? | 14:48 |
| thomasm | litong, I believe so, yes. | 14:48 |
| thomasm | litong, To tie break in cases where the timestamps are the same | 14:48 |
| openstackgerrit | gordon chung proposed a change to openstack/ceilometer: add tests for _query_to_kwargs func https://review.openstack.org/43796 | 14:49 |
| litong | @thomasm, if I add the sort on timestamp and resource_id, will that satisfy your patch? | 14:49 |
| thomasm | litong, I think so. Because the timestamps are far more precise in mongo, we should be fine. | 14:51 |
| litong | @sileht, ping | 14:51 |
| litong | @thomasm, you want to add that to db2 so that you have one patchset everything is together, or you want me to add that in a different patchset. | 14:52 |
| litong | I assume that you are adding the sort to mongodb. | 14:52 |
| swann | eglynn: I pretty sure it will be rejected to map ':' to '_' in Heat side, because I use in Heat template the special {'Ref' : 'AWS::StackId'} to build 'matching_rules' for the alarm and I have to introduce a new {'Ref' : StackIdWithoutColon} .. | 14:52 |
| thomasm | litong, I already added it to mongo, so it should work when we use the same base here for sort keys. | 14:53 |
| thomasm | litong, I just pulled the file down and I'm going to start trying to make it pass my test. :) | 14:53 |
| thomasm | litong, So, I can't use .aggregate, really? | 14:54 |
| litong | @thomasm, ok, that is great. let me know if you want me to do or provide anything. | 14:54 |
| litong | @thomasm, you can with some limitations. | 14:54 |
| thomasm | litong, Absolutely. Thanks for the help! | 14:54 |
| swann | eglynn: I'll see with angus. A solution will be to use only UUID of tenant and stack. | 14:55 |
| swann | and not ARN | 14:55 |
| eglynn | swann: yep, UUIDs would certainly be simpler | 14:55 |
| swann | eglynn: k | 14:55 |
| thomasm | litong, Alright. Let me see what I can do. Is there any documentation on what I can and can't use for aggregate? | 14:56 |
| litong | for db2 or for mongodb? | 14:56 |
| thomasm | db2 | 15:00 |
| *** dina_belova has joined #openstack-metering | 15:00 | |
| *** sandywalsh_ has joined #openstack-metering | 15:00 | |
| thomasm | litong, since I'm going to first try aggregation, I want to be sure I'm using supported features. | 15:01 |
| litong | @thomasm, in get_resources db2 impl, please do not use aggregate. since db2 aggreate does not have $first, $last, $push, $addToSet | 15:02 |
| litong | @thomasm, to use aggreagte to accomplish what mongodb did, you will need these, there is no way around that. | 15:03 |
| litong | @thomasm, so just keep what I have there by adding sort into find method. | 15:03 |
| litong | @thomasm, the sort is basically adding a sort parameter to find with a direction. | 15:04 |
| thomasm | litong, Alright - I'll aggregate in the Python. That's going to be a lot of memory use for larger clouds, I think. | 15:08 |
| thomasm | I can yield it resource by resource, though. | 15:08 |
| litong | @thomasm, if you do that, cores may not like it. | 15:09 |
| litong | @thomasm, the impact probably will be quite big. I would prefer to use the method available on server side. | 15:09 |
| litong | in this case for db2, still try to use find with combination of sort, and use aggregate for mongodb. | 15:10 |
| thomasm | litong, Then I don't see how this driver can support what we need. We shouldn't be using the resource collection because it has no regard to time. | 15:10 |
| openstackgerrit | Mehdi Abaakouk proposed a change to openstack/ceilometer: Disable the pymongo pooling feature https://review.openstack.org/44465 | 15:10 |
| thomasm | litong, Samples can be stored out of order, and we're requesting the latest representation of each resource, further complicated by a time period filter if desired. | 15:11 |
| litong | @thomasm, in that case, you would use the timestamp in meter, you can sort there, I think. | 15:11 |
| openstackgerrit | Mehdi Abaakouk proposed a change to openstack/ceilometer: Disable the pymongo pooling feature https://review.openstack.org/44465 | 15:12 |
| thomasm | litong, Hmm, I've never really worked with this before, so I'm mostly feeling my way around. That's probably why I'm confused. | 15:12 |
| thomasm | litong, So, I can get the max timestamp for each resource's sample and pull that, then? | 15:12 |
| thomasm | samples* | 15:13 |
| litong | @thomasm, I think you can do a search on meter with timestamp (whatever the way you like), get these resources ids, then | 15:13 |
| litong | @thomasm, using these resources ids to get all the resources from resource collection. | 15:13 |
| litong | in that case, the resource sorted by user_id, project_id. | 15:14 |
| litong | when you sort in meter collection, you sort by timestamp and other condition you may have. | 15:14 |
| thomasm | litong, But that still ends us up with the same problem, the resource collection has the latest stored sample for that resource, not necessarily the latest proper representation. So, filtering on a time period won't always return correct data. There are two problems: | 15:14 |
| thomasm | litong, When storing the data, there is no timestamp in the resource collection to check against, so we could overwrite with an old state, and when retrieving we could be retrieving an old state, not the latest. | 15:15 |
| thomasm | litong, So, that's why we have to pull that state from the samples, not the resource collection. | 15:16 |
| thomasm | litong, unless we want to start storing historical metadata in the resource collection, or externalize the metadata altogether. | 15:16 |
| thomasm | litong, regardless, the resource collection has no respect for time, so we can't trust it completely. | 15:17 |
| thomasm | litong, Does that make sense? | 15:17 |
| litong | @thomasm, the only timestamp we have is from meter collection, so I am not sure if you are proposing a new field for resource? | 15:17 |
| thomasm | litong, That's what I'm saying, that is how we have to filter, sort, and get the representation, that's the source of truth. | 15:18 |
| thomasm | litong, the resource collection is not, with the current implementation. | 15:18 |
| thomasm | litong, Say I'm filtering for the last week, saying I want to see what these resources were from 10 days ago to 3 days ago, the resource collection will give me what that resource is today, not what it was back then. | 15:19 |
| litong | @thomasm, in that case, I do not think we want to do that in H3, adding a field to resource table I thnk is a big deal. | 15:19 |
| *** boris-42 has quit IRC | 15:20 | |
| thomasm | litong, And since the aggregation on the samples can't be done on DB2 yet, we either have to do it manually (possibly not performant) or we have to raise the NotImplementedError and just understand that we can't fully trust that function in DB2, unless I'm missing something. | 15:20 |
| litong | @thomasm, use find for db2, and use aggregate for mongodb. | 15:21 |
| litong | in any case, the only timestamp you have is from meter collection. | 15:22 |
| litong | that is what you will have to play with regardless which method you use. | 15:22 |
| thomasm | litong, Yeah, that's what I'm concerned about without DB side aggregation. :\ | 15:22 |
| litong | @thomasm, find is done on the db side for db2. | 15:23 |
| litong | @thomasm, so is the sort. | 15:23 |
| thomasm | litong, Sure, maybe I don't fully understand all of the things find can do. | 15:23 |
| litong | when you say aggregate, I assume that you mean db.meter.aggregate, not writing python code to do aggreation manually. | 15:24 |
| thomasm | litong, Correct | 15:25 |
| thomasm | litong, Which we can't do in DB2, it sounds like. | 15:25 |
| thomasm | litong, It already works fine with the mongo driver | 15:25 |
| litong | @thomasm, you can with limitations. | 15:25 |
| litong | @thomasm, right, you are adding sort as far as I can tell. | 15:25 |
| thomasm | litong, Does aggregate for DB2 support $max? | 15:26 |
| litong | @thomasm, yes, it does. | 15:27 |
| litong | it does support $min and $max, that is about it. | 15:27 |
| litong | it does not support $first, $last, or $push. | 15:27 |
| thomasm | litong, So, what if I were to get each resource's max timestamp from the meter collection and then use that to find each resource's sample associated with that? | 15:27 |
| thomasm | litong, So, it'd be a map of resource_id to it's max timestamp, and therefore it's latest sample. | 15:28 |
| litong | I would think you want to get a list of resource ids whose timestamp fall into the range that you want to, then get these resources from resource collection | 15:28 |
| thomasm | litong, But that doesn't necessarily represent the latest state of that resource | 15:29 |
| litong | $max is fine, since you only need to get one unique resource id from meter. | 15:29 |
| litong | @thomasm, I thought that you want to use a range, between 10 days ago and 3 days ago. | 15:30 |
| thomasm | litong, The resource may have changed since 3 days ago. So, what I'm looking for is what it was like then, and what I'll get from the resource collection is what it is now. | 15:31 |
| litong | @thomasm, oh, wow, you are looking for a history. I did not get that, | 15:33 |
| litong | @thomasm, if that is the case, I do not think you can do that. | 15:33 |
| litong | I donot think anywhere we keep a history of resource. | 15:34 |
| litong | if it is changed, then it is changed | 15:34 |
| thomasm | litong, yeah. And, even if I'm not specifying a period of time, I could get an old state (because samples can be stored out of order) since there's no timestamp check when updating a resource in the collection. | 15:34 |
| thomasm | litong, we do in the samples | 15:34 |
| litong | but that is meter, not necessarily the resource. | 15:34 |
| litong | 10 days ago, the resource may not be the resource 3 days ago, (I mean resource, not meter) | 15:35 |
| thomasm | litong, each sample has a snapshot of the resource metadata and the same attributes we keep updating for that resource. That's why the mongo driver and sqlalchemy driver uses the meter collection/table instead of the resource one. | 15:35 |
| dragondm | ^yup. | 15:36 |
| thomasm | :] | 15:37 |
| dragondm | the way they do it is a little odd (fetching the resource data from the sample) but I can see why it's needed. If you want to fetch the state of a resource for billing, you want the state at the end of the billing period, not whatever it is now. | 15:37 |
| thomasm | yep | 15:39 |
| thomasm | litong, So, if that's the case, should we just expect this not to be implemented for that driver until it's supported? | 15:40 |
| thomasm | litong, If you check out my patch here: https://review.openstack.org/#/c/44277/ | 15:41 |
| thomasm | that's where I just said to raise the NotImplementedError since it can't really support it yet. | 15:41 |
| thomasm | litong, And it just skips those tests until we can implement that piece. Until then we just can't fully trust that function. | 15:42 |
| openstackgerrit | Julien Danjou proposed a change to openstack/ceilometer: doc: start the Ceilometer Guide https://review.openstack.org/44470 | 15:42 |
| litong | @thomasm, let me take a look. | 15:43 |
| *** boris-42 has joined #openstack-metering | 15:43 | |
| openstackgerrit | Julien Danjou proposed a change to openstack/ceilometer: doc: start the Ceilometer Guide https://review.openstack.org/44470 | 15:43 |
| *** fnaval_ has joined #openstack-metering | 15:43 | |
| openstackgerrit | Julien Danjou proposed a change to openstack/ceilometer: doc: start the Ceilometer Guide https://review.openstack.org/44470 | 15:43 |
| litong | @thomasm, you can not mark the entire method notimplemented. | 15:43 |
| litong | that will cause problems for db2. | 15:44 |
| *** fnaval_ has quit IRC | 15:44 | |
| litong | @thomasm, whatever test case fails, you just need to add that test case to test_impl_db2 to overwrite. | 15:44 |
| litong | so that the jenkins will work ok. | 15:45 |
| litong | @thomasm, you mark the entire method not implemented, then when db2 is hooked up, nothing will work. | 15:45 |
| *** fnaval_ has joined #openstack-metering | 15:45 | |
| thomasm | litong, Sure. That was the direction I was given since it can't really handle the base functionality of returning the trusted latest resource representation. I'm honestly fine with that, but ultimately it needs to be addressed. | 15:46 |
| thomasm | jd__, ping | 15:47 |
| litong | @thomas, let's say you add something that db2 driver fails, then you copy the test case in test_impl_db2.py, overwrite that method, | 15:47 |
| litong | @thomasm, what you are doing is killing the entire method. | 15:47 |
| thomasm | litong, I understand. Like I said, the direction I was given was to raise that since the function doesn't satisfy the basic need of returning the latest resource representation within the time period. :\ I'm not familiar at all with the DB2 work, but I suppose the reason was to be sure we put constraints on what's considered a complete driver vs. not complete. | 15:49 |
| thomasm | litong, Sorry. If the reviewers are fine with me putting passes in for those tests cases in the test_impl_db2.py, I'm alright with that. I already wrote up the bug, so we can address it. | 15:49 |
| litong | the problem when you do what you did, you invalidate the entire method which has worked for serve other purposes. | 15:49 |
| dragondm | It is a bug, which will need to be fixed in the db2 driver. | 15:49 |
| *** boris-42 has quit IRC | 15:50 | |
| litong | @dragondm, a method can provide many functions, it is ok until you add something break that, then you can not simply mark the entire method not implemented. | 15:51 |
| dragondm | actually the method does not work. It returns incorrect data. | 15:51 |
| dragondm | thomas' patch is to fix the bug for other drivers. | 15:51 |
| jd__ | thomasm: pong | 15:51 |
| litong | @dragondm, that is correct, but that fix made the entire db2 method not implemented. | 15:52 |
| dragondm | As far as raising in the method itself, vs putting some kind of skip in the tests, that's a ptl call. | 15:52 |
| *** boris-42 has joined #openstack-metering | 15:52 | |
| thomasm | ^^ that's why | 15:52 |
| jd__ | litong: either the method works and passes tests, either it doesn't pass tests; if it doesn't it needs to be fixed, if we can't fix it, it must just raises NotImplemented | 15:52 |
| jd__ | thomasm: I think litong proposed a fix you can merge right? | 15:52 |
| litong | @jd__, it works ok, until something new added to break it. when that happens, if you mark entire method not implemented, then we got | 15:53 |
| litong | problem, | 15:53 |
| litong | @jd__, ibm is pulling ceilometer code into its product, we can not mark some methods not implemented. | 15:53 |
| jd__ | litong: then IBM need to fix the driver to match what the API should return | 15:54 |
| litong | @jd__, someone early marked get_meter_statistics method entire notImplemented. I am dealing with this exactly problem now. | 15:54 |
| jd__ | litong: we don't want to have drivers returning data to the API that are not correct | 15:55 |
| litong | @jd__, IBM is trying to provide full mongodb functions in DB2, but it takes time, | 15:55 |
| jd__ | thomasm: I get that | 15:55 |
| litong | if the backend does not provide some methods, the client provided function is limited, | 15:55 |
| jd__ | litong: agreed, but in this case basic assumptions were broken | 15:55 |
| thomasm | The sort patch doesn't really address the actual problem. I have a sort key, but sorting in a resource collection doesn't really solve it - it's not holding historical data, nor is it the source of truth for the latest representation within a time period. | 15:56 |
| litong | @jd__, but what put in are working, it breaks when Thomas changed something and without using db2 specific methods/work around | 15:56 |
| dragondm | Yah, it's understandable that that is a bind, but thomas' patch is not adding new functionality. It's fixing a bug that produces incorrect output. We need to mark it somehow that "this doesn't actually work" | 15:56 |
| jd__ | litong: I don't want to be rude or anything, you just need to provide a fix on top of thomasm's patch so he can use it, there's no middle ground here | 15:57 |
| thomasm | litong, dragondm, jd__: As I understand it, the initial implementation wasn't based on the intended behavior. | 15:57 |
| litong | @thomasm, not true, | 15:58 |
| litong | it does return the resources existed in the db. | 15:58 |
| dragondm | Not the right one, tho. | 15:58 |
| litong | let's say you simply want to get resources. | 15:58 |
| jd__ | I don't negotiate driver comformance to the API | 15:58 |
| jd__ | :-) | 15:58 |
| thomasm | litong, The intended behavior is to return the latest representation of a resource for a time period, meaning it needs to support historical data, also it needs to respect time. | 15:58 |
| thomasm | litong, why would you want to without respect for what that resource is or what it was? | 16:02 |
| litong | @thomas, you simply want to get a list of resources and then you do whatever with them as you please. | 16:03 |
| litong | @thomasm , remember we only provide API and most likely it is the application calling these apis and do things with the results. | 16:04 |
| thomasm | litong, What's the point of getting a resource_id and nothing else? | 16:04 |
| thomasm | Because that's the only thing that isn't subject to change, it seems like. | 16:04 |
| dragondm | yup, which is why it's an issue. As is, if you use the api for fetching billing info (for example), you will bill on the wrong thing. The metadata will be incorrect. | 16:05 |
| dragondm | (if the backend is db2) | 16:05 |
| thomasm | yep ^^ | 16:05 |
| thomasm | litong, that's where the problem lies | 16:06 |
| litong | @thomasm, that is where problem occurs when you mark the entire method not implemented. | 16:06 |
| litong | @Thomassm, it is returning at least id, now it says not implemented. | 16:07 |
| litong | tell me they are the same thing. | 16:07 |
| *** bpokorny has quit IRC | 16:08 | |
| thomasm | litong, I don't understand why you would want a resource_id and nothing else. The purpose of that function is to return a representation of resources based on some criteria. Since that representation is subject to change, the lack of respect for time invalidates its use. | 16:08 |
| thomasm | litong, a resource_id means nothing without the attributes regarding it. | 16:09 |
| *** bpokorny has joined #openstack-metering | 16:09 | |
| thomasm | It's just a key. If the value(s) change over time, there's nothing you can do without being able to know what time they were that way. | 16:09 |
| litong | @thomasm, v2/resources works, now fails. | 16:09 |
| thomasm | litong, but it doesn't work as intended. | 16:10 |
| thomasm | litong, Which means people may see a difference in what's returned going from, say, mongodb to db2. | 16:10 |
| litong | @thomasm, if intended is to specify conditions, then it should be v2/resource?some_conditions. | 16:10 |
| *** dina_belova has quit IRC | 16:11 | |
| thomasm | litong, The default conditions aren't satisifed with this current implementation either. | 16:11 |
| thomasm | litong, That's why | 16:11 |
| *** dina_belova has joined #openstack-metering | 16:11 | |
| litong | @thomasm, either you fix the db2 driver or I fix it, but simply mark it entire not implemented is not good | 16:12 |
| litong | @thomasm, that is what I am saying. | 16:12 |
| jd__ | litong: we all know that | 16:13 |
| jd__ | time would be better spent fixing it than talking about it | 16:13 |
| jd__ | :) | 16:14 |
| litong | @jd__, agreed, just do not like to simply mark a method not implemented, that cause a big head for IBM. WE ARE PULLING CEILOMETER to our product. | 16:14 |
| jd__ | litong: I hope you realize this isn't an argument? | 16:15 |
| thomasm | litong, the tests I added were to verify an expected behavior from the default conditions. The expected behavior wasn't originally in the tests, but since I was addressing the observed problem I wanted to verify that it worked in all drivers going forward. | 16:15 |
| jd__ | it will get you nowhere arguing that | 16:15 |
| openstackgerrit | Fengqian.gao proposed a change to openstack/ceilometer: Add pagination query support for get_samples https://review.openstack.org/44492 | 16:15 |
| openstackgerrit | Fengqian.gao proposed a change to openstack/ceilometer: Add pagination support for sqlalchemy database https://review.openstack.org/35454 | 16:15 |
| openstackgerrit | Fengqian.gao proposed a change to openstack/ceilometer: Add pagination support to selected APIs https://review.openstack.org/37454 | 16:15 |
| openstackgerrit | Fengqian.gao proposed a change to openstack/ceilometer: Change pagination query method in mongodb https://review.openstack.org/41869 | 16:15 |
| *** dina_belova has quit IRC | 16:16 | |
| thomasm | litong, What I'm trying to do is be sure we document what these drivers are supposed to do in the base tests. That will always cause some issues as we try to align things, but it's important to do so we can confidently say what our API will and will not do. | 16:19 |
| thomasm | The tests will pass because they just skip when a NotImplementedError is thrown, but yes, if this is pulled down on a DB2 backend, v2/resources would fail. | 16:21 |
| thomasm | Until it's corrected | 16:21 |
| flwang | gordc: can you please revisit https://review.openstack.org/#/c/41818/ again? thanks | 16:23 |
| *** dina_belova has joined #openstack-metering | 16:23 | |
| gordc | flwang: sure. i'll take a look at it after i look at another patch. | 16:24 |
| flwang | gordc: thanks, appreciate it | 16:24 |
| *** shaneduan[afk] is now known as shaneduan | 16:25 | |
| *** dina_belova has quit IRC | 16:47 | |
| *** dina_belova has joined #openstack-metering | 16:48 | |
| *** fnaval_ has quit IRC | 16:48 | |
| *** dina_belova has quit IRC | 16:52 | |
| *** dina_belova has joined #openstack-metering | 16:53 | |
| *** fnaval_ has joined #openstack-metering | 17:03 | |
| *** shardy is now known as shardy_afk | 17:21 | |
| openstackgerrit | A change was merged to openstack/ceilometer: Fix empty metadata issue of instance https://review.openstack.org/41818 | 17:31 |
| *** dina_belova has quit IRC | 17:37 | |
| *** dina_belova has joined #openstack-metering | 17:38 | |
| *** Alexei_987 has quit IRC | 17:41 | |
| *** dina_belova has quit IRC | 17:42 | |
| *** sandywalsh_ has quit IRC | 17:43 | |
| *** fnaval_ has quit IRC | 17:48 | |
| *** sandywalsh_ has joined #openstack-metering | 17:56 | |
| *** dina_belova has joined #openstack-metering | 17:58 | |
| *** eglynn has quit IRC | 18:01 | |
| *** gordc has quit IRC | 18:04 | |
| *** gordc has joined #openstack-metering | 18:11 | |
| *** eglynn has joined #openstack-metering | 18:36 | |
| *** eglynn has quit IRC | 18:41 | |
| openstackgerrit | litong01 proposed a change to openstack/ceilometer: db2 distinct call results are different from mongodb call. https://review.openstack.org/44514 | 18:46 |
| *** litong has quit IRC | 18:54 | |
| openstackgerrit | Sandy Walsh proposed a change to openstack/ceilometer: Reject duplicate events https://review.openstack.org/44191 | 19:00 |
| *** dina_belova has quit IRC | 19:09 | |
| *** dina_belova has joined #openstack-metering | 19:10 | |
| *** dina_belova has quit IRC | 19:12 | |
| *** dina_belova has joined #openstack-metering | 19:13 | |
| *** SergeyLukjanov has quit IRC | 19:13 | |
| *** SergeyLukjanov has joined #openstack-metering | 19:15 | |
| *** boris-42 has quit IRC | 19:17 | |
| *** eglynn has joined #openstack-metering | 19:25 | |
| *** dina_belova has quit IRC | 19:27 | |
| *** dina_belova has joined #openstack-metering | 19:27 | |
| *** dina_belova has quit IRC | 19:28 | |
| *** dina_bel_ has joined #openstack-metering | 19:28 | |
| *** SergeyLukjanov has quit IRC | 19:30 | |
| *** eglynn has quit IRC | 19:30 | |
| *** thomasm has quit IRC | 19:35 | |
| *** SergeyLukjanov has joined #openstack-metering | 19:38 | |
| *** bpokorny has quit IRC | 19:43 | |
| *** openstack has joined #openstack-metering | 19:44 | |
| *** bpokorny has joined #openstack-metering | 19:44 | |
| *** eglynn has joined #openstack-metering | 19:44 | |
| openstackgerrit | Svetlana Shturm proposed a change to openstack/ceilometer: Fix wrong migrations https://review.openstack.org/44539 | 20:08 |
| *** dina_bel_ has quit IRC | 20:30 | |
| *** dina_belova has joined #openstack-metering | 20:30 | |
| *** gordc has quit IRC | 20:31 | |
| *** SergeyLukjanov has quit IRC | 20:34 | |
| *** dina_belova has quit IRC | 20:35 | |
| *** shaneduan is now known as shaneduan[afk] | 20:42 | |
| *** shaneduan[afk] is now known as shaneduan | 20:45 | |
| *** thomasm has joined #openstack-metering | 20:56 | |
| *** eglynn has quit IRC | 20:56 | |
| *** shaneduan is now known as shaneduan[afk] | 21:02 | |
| openstackgerrit | Thomas Maddox proposed a change to openstack/ceilometer: Fix to return latest resource metadata https://review.openstack.org/44277 | 21:05 |
| *** eglynn has joined #openstack-metering | 21:08 | |
| openstackgerrit | Thomas Maddox proposed a change to openstack/ceilometer: Fix to return latest resource metadata https://review.openstack.org/44277 | 21:09 |
| *** openstackgerrit has quit IRC | 21:25 | |
| *** openstackgerrit has joined #openstack-metering | 21:25 | |
| *** shaneduan[afk] is now known as shaneduan | 21:26 | |
| *** thomasm has quit IRC | 21:40 | |
| *** dina_belova has joined #openstack-metering | 21:41 | |
| *** dina_belova has quit IRC | 21:45 | |
| *** eglynn has quit IRC | 21:47 | |
| *** bpokorny has quit IRC | 21:50 | |
| openstackgerrit | Russell Bryant proposed a change to openstack/ceilometer: Sync rpc from oslo-incubator https://review.openstack.org/44561 | 22:18 |
| *** shakayumi has joined #openstack-metering | 22:26 | |
| *** alexb_ has joined #openstack-metering | 22:49 | |
| *** shanewang1 has joined #openstack-metering | 23:05 | |
| *** shanewang1 has left #openstack-metering | 23:05 | |
| *** alexb_ has quit IRC | 23:20 | |
| *** zul has joined #openstack-metering | 23:36 | |
| *** yjiang5 is now known as bmqq123 | 23:42 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!