Wednesday, 2014-06-04

*** matsuhashi has joined #openstack-ceilometer00:23
*** _nadya_ has quit IRC00:25
*** shakayumi has joined #openstack-ceilometer00:31
*** shakayumi has quit IRC00:31
*** shakayumi has joined #openstack-ceilometer00:32
*** nati_uen_ has quit IRC00:32
*** nati_ueno has joined #openstack-ceilometer00:33
*** lcostantino has quit IRC00:35
*** nati_ueno has quit IRC00:38
*** nati_ueno has joined #openstack-ceilometer00:39
*** shakayumi has quit IRC00:45
*** ddieterly has joined #openstack-ceilometer00:46
*** nati_ueno has quit IRC00:47
*** nati_ueno has joined #openstack-ceilometer00:48
*** fnaval has quit IRC00:57
*** fnaval has joined #openstack-ceilometer00:57
*** fnaval has quit IRC01:01
*** fnaval has joined #openstack-ceilometer01:03
*** _nadya_ has joined #openstack-ceilometer01:04
*** _cjones_ has quit IRC01:09
*** _cjones_ has joined #openstack-ceilometer01:09
*** `jpg has quit IRC01:13
*** _cjones_ has quit IRC01:14
*** nati_uen_ has joined #openstack-ceilometer01:18
*** nati_ueno has quit IRC01:22
*** nosnos has joined #openstack-ceilometer01:38
*** nati_uen_ has quit IRC01:39
*** nati_ueno has joined #openstack-ceilometer01:39
*** caynan has joined #openstack-ceilometer01:42
*** _nadya__ has joined #openstack-ceilometer01:49
*** _nadya_ has quit IRC01:50
*** r3pl4y has joined #openstack-ceilometer01:52
*** _nadya__ has quit IRC01:53
openstackgerritliusheng proposed a change to openstack/ceilometer: Fix notification for NotImplemented record_events
openstackgerritliusheng proposed a change to openstack/ceilometer: Fix notification for NotImplemented record_events
openstackgerritliusheng proposed a change to openstack/ceilometer: Check unsupported query filters of listing events
*** _nadya_ has joined #openstack-ceilometer02:17
openstackgerritMauro Stettler proposed a change to openstack/ceilometer: Corrects a flaw in the treatment of swift endpoints
*** `jpg has joined #openstack-ceilometer02:20
*** harlowja is now known as harlowja_away02:42
*** fnaval has quit IRC02:44
openstackgerritliusheng proposed a change to openstack/python-ceilometerclient: Provide explicit help string of resource-metadata
openstackgerritliusheng proposed a change to openstack/python-ceilometerclient: Provide explicit help string of resource-metadata
openstackgerritliusheng proposed a change to openstack/python-ceilometerclient: Provide explicit help string of resource-metadata
*** changbl has joined #openstack-ceilometer03:08
*** rwsu has quit IRC03:10
openstackgerritliusheng proposed a change to openstack/ceilometer: Fix the notification of floatingip association
*** nosnos has quit IRC03:29
*** fnaval has joined #openstack-ceilometer03:30
*** matsuhashi has quit IRC03:31
openstackgerritZhiQiang Fan proposed a change to openstack/ceilometer: set debug to true in api test
openstackgerritliusheng proposed a change to openstack/ceilometer: Improve the timestamp validation of ceilometer API
*** Longgeek has joined #openstack-ceilometer03:33
*** ddieterly has quit IRC03:46
*** ddieterly has joined #openstack-ceilometer03:47
*** skelpter has joined #openstack-ceilometer03:52
openstackgerritMauro Stettler proposed a change to openstack/ceilometer: Corrects a flaw in the treatment of swift endpoints
*** `jpg has quit IRC04:05
*** fnaval has quit IRC04:19
*** matsuhashi has joined #openstack-ceilometer04:25
*** nosnos has joined #openstack-ceilometer04:26
*** r3pl4y has quit IRC04:37
*** psharma has joined #openstack-ceilometer04:39
*** `jpg has joined #openstack-ceilometer04:54
*** nati_ueno has quit IRC04:55
*** Longgeek has quit IRC04:56
*** nati_uen_ has joined #openstack-ceilometer04:57
*** nati_uen_ has quit IRC04:57
*** Longgeek has joined #openstack-ceilometer05:01
*** ildikov has quit IRC05:04
*** shakamunyi has joined #openstack-ceilometer05:04
*** underyx is now known as Underyx|off05:12
*** ildikov has joined #openstack-ceilometer05:35
*** alexpilotti has joined #openstack-ceilometer05:39
*** skelpter has left #openstack-ceilometer05:48
*** _nadya_ has quit IRC05:49
*** alexpilotti has quit IRC05:54
*** eglynn_ has joined #openstack-ceilometer05:56
*** r3pl4y has joined #openstack-ceilometer06:00
*** alexpilotti has joined #openstack-ceilometer06:01
openstackgerritOpenStack Proposal Bot proposed a change to openstack/ceilometer: Imported Translations from Transifex
*** `jpg has quit IRC06:03
*** nati_ueno has joined #openstack-ceilometer06:10
eglynn_DinaBelova: o/06:16
*** r3pl4y has quit IRC06:16
*** _nadya_ has joined #openstack-ceilometer06:16
eglynn_DinaBelova: FYI I brought up that capabilities API versus static test-excluding config conumdrum with mtreinish last night06:17
*** r3pl4y has joined #openstack-ceilometer06:17
eglynn_... at the project/release status meeting, then spilled over to #openstack-qa06:17
eglynn_... search for "eglynn has joined #openstack-qa"06:17
eglynn_... his PoV is slightly clearer to me now06:19
eglynn_... tho' there is a lack of consistency across the tempest-against-public-cloud-X versus tempest-in-the-gate cases06:19
*** r3pl4y has quit IRC06:21
*** r3pl4y has joined #openstack-ceilometer06:22
openstackgerritMauro Stettler proposed a change to openstack/ceilometer: Corrects a flaw in the treatment of swift endpoints
*** Ruetobas has quit IRC06:25
*** nati_ueno has quit IRC06:28
*** Ruetobas has joined #openstack-ceilometer06:31
*** Ruetobas has quit IRC06:35
*** Ruetobas has joined #openstack-ceilometer06:35
*** cdent has joined #openstack-ceilometer06:37
*** lsmola has quit IRC06:40
*** cdent has quit IRC06:46
*** alexpilotti has quit IRC06:59
*** _nadya_ has quit IRC07:04
*** Underyx|off is now known as underyx07:04
*** r3pl4y has quit IRC07:09
*** idegtiarov has joined #openstack-ceilometer07:10
*** r3pl4y has joined #openstack-ceilometer07:11
*** matsuhashi has quit IRC07:17
*** matsuhashi has joined #openstack-ceilometer07:18
*** eglynn_ is now known as eglynn-afk07:21
openstackgerritliusheng proposed a change to openstack/ceilometer: Fix notification for NotImplemented record_events
*** _nadya_ has joined #openstack-ceilometer07:30
*** Alexei_987 has quit IRC07:33
openstackgerritMehdi Abaakouk proposed a change to openstack/ceilometer: Iterates swift response earlier to get the correct status
*** renlt has joined #openstack-ceilometer07:46
*** eglynn-afk is now known as eglynn_07:47
*** r3pl4y has quit IRC07:49
*** r3pl4y has joined #openstack-ceilometer07:51
*** nacim has quit IRC07:58
*** nacim has joined #openstack-ceilometer07:58
*** r3pl4y has quit IRC08:00
*** r3pl4y has joined #openstack-ceilometer08:01
*** `jpg has joined #openstack-ceilometer08:06
*** r3pl4y has quit IRC08:07
*** nacim has quit IRC08:07
*** nacim has joined #openstack-ceilometer08:09
*** r3pl4y has joined #openstack-ceilometer08:09
*** shakamunyi has quit IRC08:10
*** idegtiarov has quit IRC08:15
*** idegtiarov has joined #openstack-ceilometer08:17
ildikovsileht: hi. are you around?08:21
silehtildikov, o/08:25
*** Longgeek has quit IRC08:27
*** Longgeek has joined #openstack-ceilometer08:28
*** Longgeek has quit IRC08:29
*** Longgeek has joined #openstack-ceilometer08:30
*** r0j4z0 has quit IRC08:30
*** safchain has joined #openstack-ceilometer08:31
*** Alexei_987 has joined #openstack-ceilometer08:33
ildikovsileht: you made the oslo.messaging swap, so I thought that maybe you have some answers for my questions08:34
ildikovsileht: I'm working on fixing the doc generation errors and warnings08:35
*** IvanBerezovskiy1 has joined #openstack-ceilometer08:35
*** _nadya_ has quit IRC08:35
* sileht listens08:35
*** _nadya_ has joined #openstack-ceilometer08:35
ildikovsileht: dhellmann fixed the autoindex for source code dodc generation08:35
ildikovsileht: so the doc generation now works, but it failed with some imports08:36
ildikovsileht: so I started to investigate a bit and I found the for instance the ceilometer.openstack.common.notifier code was removed08:36
ildikovsileht: but there are still imports that refer to that code08:36
ildikovsileht: there is a similar import which would call nova.openstack.common.notifier.api, but it was deleted also from nova08:37
ildikovsileht: so this is the big story08:38
ildikovsileht: my plan is to clean up a bit, the question is how to do this clean up08:39
silehtildikov, I see08:39
ildikovsileht: I hope that you know better these parts of the code than me08:39
silehtildikov, each items have a different story08:39
silehtcode must  be update to handle oslo.messaging or old rpc code (not only old code)08:40
silehtfor I guess it can be removed from ceilometer ?08:40
silehtand for I think this code looks currently broken08:41
ildikovI think so too, I just needed a second opinion :)08:41
ildikovI thought about this last one too that it could be deleted08:41
*** hoangdo has joined #openstack-ceilometer08:41
*** matsuhashi has quit IRC08:42
ildikovso the question is in this last case that can it be fixed or it should be rewritten according to the changes?08:43
hoangdohello everyone08:43
silehtildikov, for the last one it's needed to get compute sample one last time before a instance is deleted08:44
silehtildikov, the good way to fix it, is to improve the instance.delete notification in nova, but this is a huge work08:44
silehtildikov, the quick fix is to use the new nova notifier code08:45
hoangdowe would like to dev a plugin: getting info from a software running on VMs (more specific: rabbitmq) instead of general info like CPU, RAM, Network, etc. I wonder is it the right way to do with Ceilometer08:45
*** caynan has quit IRC08:47
ildikovsileht: a-ha, so this module is to get that last sample and this could be done by using the new nove notifier code?08:47
*** ildikov has quit IRC08:48
*** changbl has quit IRC08:48
*** openstackgerrit has quit IRC08:48
*** IvanBerezovskiy1 has quit IRC08:48
*** ityaptin has quit IRC08:48
*** liusheng has quit IRC08:48
*** ityaptin has joined #openstack-ceilometer08:48
eglynn_hoangdo: we don't have any facility currently to gather metrics from applications/services running *within* the VM08:48
*** IvanBerezovskiy has joined #openstack-ceilometer08:48
*** changbl has joined #openstack-ceilometer08:49
*** ildikov has joined #openstack-ceilometer08:49
*** IvanBerezovskiy has left #openstack-ceilometer08:49
*** IvanBerezovskiy has joined #openstack-ceilometer08:49
ildikovsileht: what is missing from that Nova notif?08:49
*** liusheng has joined #openstack-ceilometer08:49
*** openstackgerrit has joined #openstack-ceilometer08:49
*** matsuhashi has joined #openstack-ceilometer08:50
eglynn_hoangdo: ... instead all metrics are gathered from the outside-in (by polling the hypervisor layer)08:50
openstackgerritAlexei Kornienko proposed a change to openstack/ceilometer: Refactor tests to remove direct access to test DBManagers
eglynn_hoangdo: ... gathering metrics instead from the inside-out would present some issues08:51
hoangdoeglynn_: so it's impossible? We want Heat to scale not on CPU or RAM but on message broker queue. Do you have any suggestion08:52
eglynn_hoangdo: ... for example if the approach required an agent to be installed inside the VM, this would require propogating credentials so that the agent can POST datapoints to the ceilometer-api08:52
silehtildikov, some note I have made, the last time I have tracked this issue:
eglynn_hoangdo: ... not impossible, but v. awkward to do if these data can't be surfaced from *outside* the VM08:52
eglynn_hoangdo: ... that's one of the main reasons heat want to use ceilo for alarming (on CPU util) to drive autoscaling08:53
ildikovsileht: thanks08:53
eglynn_hoangdo: ... as the original heat approach required installing a heat cfn-push-stats agent in the VM08:53
ildikovsileht: it's for the third, nova_notifier item, right?08:54
ildikovsileht: for the second, we both think it could be deleted08:54
silehtildikov, yes08:55
silehtildikov, and yes08:55
hoangdoeglynn_: well I understand it's very strange to use an "inside" agent. But that's what we really need now. For example, in our case, we monitor the Message Broker queues, if some queue is full, we don't need to scale the Message Broker node, but we scale the "Handler" nodes which receive/process data from that queue.08:57
hoangdoeglynn_: I don't know what is the best practice for this08:57
ildikovsileht: and for the first, log_handler one, it should now support oslo.messaging and rpc too?08:58
eglynn_hoangdo: can that data not be surfaced outside the VM?08:59
hoangdoeglynn_: I guessed no.09:00
silehtildikov, it should support both, at least until K09:00
eglynn_hoangdo: ... in that case, you'd need to figure out some way of (a) ensuring the agent is installed on-VM and (b) propogating credentials to that agent09:00
ildikovsileht: thanks for the good news :)09:00
eglynn_hoangdo: ... (a) is prolly straigtforward *if* you control the VM image09:00
ildikovsileht: I just wanted to fix the doc :)09:01
silehtildikov, welcome09:01
eglynn_hoangdo: ... (b) is not straightforward09:01
ildikovsileht: also thanks for the help, it can happen that I will ask some further questions, but I think I have enough info for now09:01
eglynn_hoangdo: ... one of the problems is that keystone tokens have a limited lifetime09:02
hoangdo(a) is ok, we can create our own image09:02
eglynn_hoangdo: ... and it's unlikely you'd want to expose a user name and passwd onto the VM09:02
eglynn_hoangdo: .... perhaps keystone trusts could be use to delegate very limited privilege to such an agent09:02
hoangdoeglynn_: you're right, expose OpenStack username and pass to VMs is too strange09:03
eglynn_hoangdo: exactly09:04
eglynn_hoangdo: ... passing in a token also is problematic as it would need to be regularly refreshed09:05
eglynn_hoangdo: ... so trusts are probably the lesser of 3 evils09:05
hoangdoeglynn_ I'm lost ^^. What's the best practice in this case. I'm sure someone must need this use case before me. It's pretty common09:05
eglynn_hoangdo: ... lost?09:06
eglynn_hoangdo: ... lost at what point09:06
eglynn_boris-42: o/09:07
boris-42eglynn_ o+)09:07
hoangdoeglynn_: well I don't want to "hack". My intend is following the common practice and dev a plugin.09:07
boris-42eglynn_ it's hangout?09:07
boris-42eglynn_ hangout our irc?)09:08
eglynn_boris-42: let's just IRC, I'm stuck with a low-bandwidth connection this morning09:08
boris-42eglynn_ heh09:08
eglynn_hoangdo: ... as I said, it's not something we do directly right now09:08
boris-42eglynn_ so we were speaking about operators program09:08
boris-42eglynn_ and making operators life easier=)09:08
eglynn_hoangdo: ... I think keystone trusts *may* provide a path to making it possible09:08
eglynn_hoangdo: ... but you probably would need to clarify/confirm that with the keystone domain experts09:09
eglynn_hoangdo: ... make sense?09:09
hoangdoeglynn_: yes. thanks. I think I'll search for other solution before come back to this.09:10
eglynn_hoangdo: cool, thanks!09:10
eglynn_boris-42: yeah, making operators lives easier ... we're all about that! :)09:11
eglynn_boris-42: ... so how are we going to acheive that?09:13
boris-42eglynn_ so I am working on doc09:15
boris-42eglynn_ that explains how=)09:15
boris-42eglynn_ basically we almost have everything09:15
boris-42eglynn_ so what we need is next09:16
boris-421) horizon plugin that will be control plane09:16
eglynn_boris-42: cool, is the doc in the public domain somewhere?09:16
boris-42eglynn_ not yet=)09:16
boris-42eglynn_ didn't finished it09:16
boris-42eglynn_ too important document to make it of half of hour=)09:16
boris-42so but principles are quite simple09:16
eglynn_boris-42: once the doc is finished, will be opening it up for review?09:17
boris-42eglynn_ yep09:17
boris-42eglynn_ in mailing list=)09:17
eglynn_boris-42: cool, I'll look forward to reading it09:17
boris-42eglynn_ so what we need is to combine together 1) ceilometer 2) osprofiler 3) rally 4) satori 5) rubick under horizon plugin as a control plane09:17
eglynn_boris-42: for context on the channel, do you wanna give a one-liner for each of items 2) thru' 5)?09:19
boris-42sure (actually typing)09:19
boris-422) osprofiler allows us to trace request through all services09:20
boris-42dev case I already presented on summit09:20
boris-42but there is as well operators case09:20
boris-42we can track what amount of time request work in what service09:20
boris-42and draw stacked area09:20
eglynn_yep, so osprofiler is tool to measure the fine-grained latency of distributed openstack interactions by propogating a request ID with RPC calls09:21
boris-42eglynn_ yep09:21
boris-423) rally - will allow us to run periodical benchmarks09:21
boris-42that can measure OpenStack API, VMs, Netowrk performance of cloud09:21
*** Infitialis has joined #openstack-ceilometer09:21
boris-42as well we can have notification if something went wrong (i mean email operator)09:22
boris-42or requests takes too much09:22
boris-42as well as rally has integrated tempest we can make health checks based on taht09:22
boris-42e.g. running smoke tests periodically09:22
eglynn_boris-42: intended to run against a "live" cloud?09:23
boris-424) satori - it discovers configuration of everything in cloud09:23
boris-42eglynn_ yep09:23
boris-42eglynn_ I know tempest cleanup mechanism should be improved before that=)09:23
boris-42eglynn_ but we can start from rally benchmarks=)09:23
eglynn_boris-42: WRT satori ... including scattered text-based config like ceilo pipeline.yaml or glance policy.json etc?09:24
*** lsmola has joined #openstack-ceilometer09:25
boris-42eglynn_ ?09:25
boris-42eglynn_ it should discover everything that is possible and even a bit more09:25
eglynn_boris-42: reason I ask it that ...09:26
eglynn_boris-42: we discussed at summit alternative ways of managing the info embedded in the ceilometer pipeline.yaml09:27
eglynn_boris-42: ... as currently this is a flat text file propogated all over the place09:27
eglynn_boris-42: ... so difficult to ensure consistency and also problematic to push detailed deployment-specific info into the pipeline.yamls09:28
boris-42eglynn_ I think the best solution is to have only one config argument09:28
eglynn_boris-42: ... e..g. ildikov had a requirement to expose project UUIDs into the pipeline.yaml for tenant-specific metering09:28
boris-42eglynn_ where is the DB09:28
ildikovhi All09:28
boris-42eglynn_ and store all info in DB=) but it's if you are asking me=)09:28
ildikovyes, I'm the one to blame ;)09:29
boris-42ildikov hey there=)09:29
eglynn_boris-42: well that's the point, this info is not in DB currently09:29
boris-42eglynn_ I mean it's the one more big issue of arch of OpenStack09:29
eglynn_boris-42: ... it's in a /etc/ceilometer/pipeline.yaml file on every compute node and ceilo controller host09:29
openstackgerritZhiQiang Fan proposed a change to openstack/python-ceilometerclient: Fix alarm-threshold-update --query option
boris-42eglynn_ so actually satori is not only about that stuff09:30
ildikovboris-42: the plan is to store the config in DB and provide the possibility to dynamically reconfigure the system, but this solution needs a longer timeframe09:30
boris-42ildikov so you are going to work on it?09:30
ildikovboris-42: me and nealph is also inetersted because it would be useful for TripleO too09:31
*** r0j4z0 has joined #openstack-ceilometer09:31
boris-42eglynn_ ildikov  okay guys it will be nice =)09:31
ildikovboris-42: we are kind of waiting for the TSDaaS with the design, but I would like to start working on this as soon as we can09:31
boris-42to have but it's not related to current discussion=)09:31
eglynn_boris-42: yeah I was just wondering whether satori could potentially help out with that distributed config file issue09:31
boris-42eglynn_ but it's not only about that, it has even more bigger scope09:32
eglynn_boris-42: sure09:32
boris-42eglynn_ it discovers configuration of system, hardware and so on09:32
ildikovboris-42: Time Series Data aaS :)09:32
eglynn_boris-42: a-ha, fair enough09:32
ildikovboris-42: yes, I just did not want to mention anything food related at lunchtime ;)09:33
boris-42eglynn_ so next thing is rubick09:33
eglynn_boris-42: ... right I've prolly side-tracked you a bit, so please carry on09:33
boris-42ildikov hehe=)09:33
boris-42eglynn_ so the next thing is rubick09:33
* eglynn_ listens ...09:34
boris-42it will make smart analyze based on rules and whatever to analyze what issues we have in clouds09:34
boris-42and troubleshooting sutff09:34
boris-42so where and what can produce potential (or produce real) issues09:34
eglynn_interesting, as in runs analytics over the timing data collected by osprofiler?09:35
boris-42eglynn_ nope at this moment it is collecting data by self as I know09:35
boris-42eglynn_ but there will be some kind of integration satori and rubick09:36
boris-42eglynn_ so it will analyze info from satori09:36
eglynn_boris-42: fair enough09:36
boris-42eglynn_ as well what I think is to analyze osprofiler data (in future) and notifications09:36
boris-42eglynn_ e.g. some host started working slower then usually09:36
boris-42eglynn_ and you get babaha notifiertion in horizon09:36
eglynn_boris-42: ... initially rubick sounded similar to how rackspace use stacktach data to detect operational anomolies in near-realtime09:36
boris-42eglynn_ on host XXX potsntial issues09:36
boris-42eglynn_ and then you can retriwe via web UI09:37
boris-42all info about that host / hardware / probably logs09:37
boris-42you can run with rally some benchmarks related to issue on that host and collect profiling info09:38
boris-42and do all these stuff via Horizon Pluging09:38
boris-42as well there should be one more project called logging-as-a-service09:38
eglynn_interesting: "Heat metadata plugin extracts configration metadata from Heat stacks created by TripleO/Tuskar service"09:39
boris-42eglynn_ it was the initial goal09:39
eglynn_I suspect Tuskar would be playing in a somewhat similar space?09:39
boris-42eglynn_ not sure09:39
boris-42eglynn_ tuskar web ui for trippleO?09:39
eglynn_boris-42: kinda09:40
eglynn_boris-42: ... with some extra smarts09:40
boris-42eglynn_ actually not sure09:40
boris-42eglynn_ that all OpenStack users would like to use triple with tuskar09:40
boris-42to understand what the hell is happening with cloud=)09:40
boris-42eglynn_ so back to rubick (after summit, they changed a bit direction, to use satori )09:41
eglynn_boris-42: extra smarts would be around stuff like datacenter build-out planning, provisioning new h/w according to its best role etc., visualizing SNMP metrics etc.09:41
boris-42eglynn_I am still not sure that Tuskar should be it09:42
boris-42eglynn_ any way we will discuss this stuff in mailing list (about Tuskar)09:42
eglynn_I wonder also are the rubick guys aware of the new convergence direction that heat is taking?09:42
eglynn_convergence == "on stack update, compare modified stack template to *current reality*"09:43
eglynn_old approach == "on stack update, compare modified stack template to original stack template"09:43
boris-42eglynn_ one sec09:43
*** ogelbukh has joined #openstack-ceilometer09:44
eglynn_IIUC the notion09:44
boris-42ogelbukh ^09:44
boris-42ogelbukh he is rubick guy=)09:44
boris-42eglynn_ ^09:44
ogelbukhboris-42: hello09:44
eglynn_ogelbukh: welcome09:44
boris-42ogelbukh hi there09:44
eglynn_ogelbukh: you could tail to get the context09:44
ogelbukheglynn_: thank you09:44
boris-42eglynn_ btw09:45
boris-42eglynn_ probably osprofiler should be a part of ceilometer program?09:46
boris-42eglynn_ cause it's mostly related to it=)09:46
boris-42eglynn_ or operators one of those=)09:46
eglynn_boris-42: ... that's a good question09:46
boris-42eglynn_ if we have operators program then it can be there..09:47
eglynn_boris-42: ... I don't know if there's much benefit to a tool like osprofiler to be part of an integrated release09:47
boris-42eglynn_ yep probably just keep it on stackforge09:47
boris-42eglynn_ it will simplify work on it lol09:47
eglynn_boris-42: ... yeah it's kind of ancilliary to the core cloud, though definitely very useful09:48
*** Qu310 has quit IRC09:48
eglynn_boris-42: ... also there's the whole DefCore thing in the background09:48
*** Qu310 has joined #openstack-ceilometer09:48
boris-42eglynn_ oh defcore currently is something bad=)09:48
eglynn_boris-42: ... yep, it's scarey to define the capabilities of the cloud in terms of tempest test that existed two cycles back in time09:49
boris-42eglynn_ yep=)09:49
boris-42eglynn_ exactly but I was more polite*09:49
eglynn_boris-42: LOL :)09:49
eglynn_boris-42: ... so what's the timeline for you publishing your master document?09:50
eglynn_boris-42: ... sounds like it'll make for very interesting reading :)09:50
boris-42eglynn_ yep =)09:50
boris-42eglynn_ so actually I should make it on this week09:50
eglynn_boris-42: cool09:50
boris-42eglynn_ I hope tomorrow I will finish09:50
boris-42eglynn_ btw we will need to make deep dive09:51
eglynn_boris-42: excellent, no doubt it'll generate a lot of traffic/interest on the ML09:51
boris-42eglynn_ lol=)09:51
eglynn_boris-42: deep-dive reviewing of the doc, or deep-dive prototyping up the ideas expressed in the doc?09:52
boris-42eglynn_ deep dive to adopt osprofiler to profile ceilometer09:53
*** underyx is now known as Underyx|off09:54
boris-42eglynn_ that is the last concern that I didn't address in osprofiler09:54
eglynn_boris-42: a-ha, cool ... the circular profiling :)09:54
boris-42eglynn_ yep09:54
ogelbukhwho is profiling the profiler09:54
eglynn_boris-42: BTW what version of ceilo are you targeting, and which storage driver?09:54
boris-42ogelbukh we are+)09:54
ogelbukhprofiler is )09:55
boris-42eglynn_ I was using SQL storage09:55
boris-42eglynn_ and current master on time of summit09:55
boris-42eglynn_ it's already a bit out of date I'll probably need to rebase09:55
eglynn_boris-42: reason I asked, is that until very recent the performance of the sql-a driver was simply not viable09:55
eglynn_boris-42: ... this has improved significantly since summit09:55
boris-42eglynn_ yep sure but osprofile doesn't care of backedn09:56
eglynn_boris-42: ... but still, mongodb would be the only realistic option for production09:56
boris-42eglynn_ it's about ceilometer how to store data09:56
boris-42eglynn_ I mean osprofiler is not related to the backend at all=)09:56
eglynn_boris-42: it wouldn't profile the latency of the collector persisting data in the metering store?09:57
boris-42eglynn_ hm but there are 2 timestamps09:57
eglynn_boris-42: ... or profile the latency of API calls that are satisfied with queries on the metering store?09:57
boris-42eglynn_ as I understood09:57
boris-42eglynn_ one is generated on when we are sending message09:57
boris-42eglynn_ another when it was consumed09:57
eglynn_boris-42: two timestamps on metering data?09:57
*** vrovachev has joined #openstack-ceilometer09:57
boris-42eglynn_ one sec09:57
eglynn_boris-42: ... yep one timestamp when data acquired, and another when data is recorded09:58
boris-42eglynn_ so I am using only timestampt09:58
boris-42do I need to analyze when it was recorded?09:58
eglynn_boris-42: ... delta between those two timestamps gives approximate total latency of ceilometer pipeline09:58
eglynn_boris-42: ... but not the fine-grained latency09:59
*** renlt has quit IRC09:59
boris-42eglynn_ so yep it's related to profiling ceilometer =)09:59
*** r3pl4y has quit IRC10:00
eglynn_boris-42:  in that paste ... "recorded_at": "2014-05-06T02:53:03.110724" MINUS "timestamp": "2014-05-06T02:52:59.357020" EQUALS ~11s10:00
boris-42eglynn_ hehe=)10:00
boris-42eglynn_ devstack installation under load lol10:00
boris-42eglynn_ in VM10:00
boris-42eglynn_ with 2cores and 4gb ram10:01
eglynn_boris-42: so I thought that osprofiling ceilo would yield more detailed fine-grained step-wise latency than that?10:01
eglynn_boris-42: ... yep, which why I made the point above about sql-a10:01
*** r3pl4y has joined #openstack-ceilometer10:01
boris-42eglynn_ so my goal on summit was to cobine everything togeterh10:01
boris-42eglynn_ and show that it works and can work without big changes10:02
eglynn_boris-42: recommendation would be profile ceilo against mongo as that's the only driver recommended by many distros for production10:02
boris-42eglynn_ yep sure in real situation we are going to that10:02
eglynn_boris-42: (e.g. RDO and the Mirantis distro both only support mongo)10:02
boris-42eglynn_ as well as it should be multimode installation10:02
boris-42eglynn_ and sql backend for openstack & for ceilometer10:02
boris-42should be on different nodes=)10:02
eglynn_boris-42: also sql-a at the time of summit can be taken as broken and uneffectively unusable10:03
boris-42but it's not related to the code at all=) it's more about how to use it10:03
boris-42eglynn_ argree?10:03
eglynn_boris-42: agree with "but it's not related to the code at all=) it's more about how to use it" ?10:03
eglynn_boris-42: not sure I understand what you meant by that statement10:04
boris-42I mean10:04
boris-42osproifler doesn't care about backends and other stuff10:04
boris-42it just thing that sends special notifications10:04
boris-42so at this point we are discussing not osprofiler by self10:05
eglynn_boris-42: sure, my point was that it would be a waste of time to profile ceilometer in a non-realistic configuration10:05
boris-42but what is the best deployment to profile openstack cloud10:05
boris-42eglynn_ yep but that things profile everything except ceilometer=)10:05
eglynn_boris-42: ... i.e. using a broken version of storage driver not supported for prod10:05
boris-42eglynn_ so agree that that data is not releastic in case of ceilometer10:06
eglynn_boris-42: yeah, so I thought we were discussing using osprofiler to start profile ceilometer itself *also*?10:06
boris-42eglynn_ but it shows that we are doing 120 db request do boot single VM10:06
boris-42eglynn_ yep we should10:06
boris-42eglynn_ but as well I don't think that osprofiler should depend on what backend we are using10:07
boris-42eglynn_ it should work in the same way, but results will be different10:07
boris-42eglynn_ launch time10:07
boris-42eglynn_ be back soon10:07
eglynn_boris-42: ... I agree, just pointing out that there's no sense in using a driver configuration known to be broken10:07
boris-42eglynn_ hehe=)10:07
boris-42eglynn_ sure10:07
*** nosnos has quit IRC10:08
eglynn_boris-42: ... cool enough, bon appetit!10:08
boris-42eglynn_ see u10:08
silehtDinaBelova, can you removed the -1 about infra issue on this review ?10:17
*** r3pl4y has quit IRC10:19
*** r3pl4y has joined #openstack-ceilometer10:21
*** matsuhashi has quit IRC10:24
*** Underyx|off is now known as underyx10:32
*** Longgeek has quit IRC10:34
*** Longgeek has joined #openstack-ceilometer10:35
*** shakamunyi has joined #openstack-ceilometer10:37
zqfaneglynn: hi, can you please review the patch:
eglynn_zqfan: looking10:38
silehtDinaBelova, thx10:40
zqfaneglynn, thanks10:41
DinaBelovasileht, yeah, np :) I'm still not sure how these +1/-1 are appearing - as that's new patch set, but still -110:41
DinaBelovastrange :)10:41
*** shakamunyi has quit IRC10:41
r0j4z0hi all10:44
r0j4z0on the notification agent, im able to pipeline only certain events?10:44
r0j4z0for example if i want to store samples only with compute.instance.create.end10:45
r0j4z0the idea is be able to fire an alarm when some random event occurs10:46
*** matsuhashi has joined #openstack-ceilometer10:47
eglynn_r0j4z0: we don't support the notion of alarming on events10:50
eglynn_r0j4z0: rather we alarm on statistics10:50
eglynn_r0j4z0: ... i.e. when an aggregated statistic cross some threshold10:50
eglynn_r0j4z0: ... an alarming on notifications BP was targeted at icehouse-3 but the implementation wasn't accepted onto master10:51
r0j4z0i see...10:51
*** _nadya_ has quit IRC10:51
r0j4z0then i cant store events as samples and then alarm based on that samples using some query10:52
zqfanhi, I find that ceilometer-specs has two files which are exactly same: specs/template.rst and specs/juno/template.rst, I want to remove the juno/template.rst, is it ok?10:52
eglynn_r0j4z0: ... you can derive samples from notifications and alarm on the trend of values of those samples10:53
eglynn_zqfan: one is a link to the other10:53
eglynn_zqfan: we may have per-cycle versions of the template in the future10:54
r0j4z0thank you eglynn_ i will try that :D10:55
eglynn_zqfan: ... I just followed on the tripleo-specs led in that regard ...
*** nacim has quit IRC10:55
eglynn_zqfan: ... but I'm not too fussed about it one way or the other10:55
r0j4z0eglynn_ is
zqfaneglynn, oh yes, it is a link, sorry, not notice that10:57
eglynn_r0j4z0: ... yep, that's the one10:58
r0j4z0that is just what i needed!!10:58
eglynn_r0j4z0: ... we may be able to resurrect this once the events API is implemented for all storage drivers10:58
eglynn_r0j4z0: (... currently only sql-a, but planned for mongo & hbase)10:59
r0j4z0i see10:59
r0j4z0then the only option is to have a consumer on the queue to get the events and parse by myself to get alarmed when an event occurs11:00
*** r3pl4y has quit IRC11:00
*** r3pl4y has joined #openstack-ceilometer11:01
r0j4z0or query the API each X seconds to get the events and traits11:02
*** _nadya_ has joined #openstack-ceilometer11:05
*** zqfan has quit IRC11:14
openstackgerritPradeep Kilambi proposed a change to openstack/ceilometer-specs: Spec for metering LBaaS
*** matsuhashi has quit IRC11:25
*** matsuhashi has joined #openstack-ceilometer11:26
*** matsuhashi has quit IRC11:29
*** matsuhashi has joined #openstack-ceilometer11:29
eglynn_r0j4z0: yeap, unless the event of interest can be easily mapped on to a numerical value11:33
eglynn_r0j4z0: ... in which case you could have a notification handler to consume the event & emit a sample, then alarm on the trend in values of that sample type11:34
*** nacim has joined #openstack-ceilometer11:34
r0j4z0eglynn_ yes but the idea was to have an alarm with the data on the payload of the event, for example with the fixed_ips on compute.instance.create.end to be able to bootstrap the image using the event11:37
eglynn_r0j4z0: in that case, a statistics-based approach clearly wouldn't be appropriate11:38
r0j4z0i think the best approach is to have a consumer on the notification queue and send the notification when the event occurs by myslef11:39
eglynn_r0j4z0: yep, sounds reasonable11:40
*** Alexei_987 has quit IRC11:42
*** Alexei_987 has joined #openstack-ceilometer11:42
*** r3pl4y has quit IRC11:46
*** r3pl4y has joined #openstack-ceilometer11:48
*** alexpilotti has joined #openstack-ceilometer11:53
*** nacim has quit IRC11:54
*** r3pl4y has quit IRC11:58
*** r3pl4y has joined #openstack-ceilometer12:00
*** promulo has quit IRC12:03
openstackgerritPradeep Kilambi proposed a change to openstack/ceilometer-specs: Spec for metering LBaaS
openstackgerritAlexei Kornienko proposed a change to openstack/ceilometer: Refactor tests to remove direct access to test DBManagers
*** alexpilotti has quit IRC12:07
openstackgerritNadya Privalova proposed a change to openstack/ceilometer: [HBase] get_resource optimization
*** lcostantino has joined #openstack-ceilometer12:16
*** alexpilotti has joined #openstack-ceilometer12:22
*** jdob has joined #openstack-ceilometer12:22
*** r3pl4y has quit IRC12:22
*** lcostantino has quit IRC12:23
*** r3pl4y has joined #openstack-ceilometer12:24
*** ddieterly has quit IRC12:27
*** ddieterly has joined #openstack-ceilometer12:27
openstackgerritA change was merged to openstack/ceilometer: Improve performance of api requests with hbase scan
*** eglynn_ has quit IRC12:32
*** cmart has joined #openstack-ceilometer12:46
*** `jpg has quit IRC12:52
*** psharma has quit IRC12:52
*** anand_ts has joined #openstack-ceilometer12:54
*** `jpg has joined #openstack-ceilometer12:54
*** fnaval has joined #openstack-ceilometer12:55
cmartJust for you guys to check it out. There is a thread in the ML with designs related to the Alarm Management Page.It will be great to have your feedback :) (
*** ddieterly has quit IRC12:58
openstackgerritPooja Tiwari proposed a change to openstack/ceilometer: Alarm default description update
*** r3pl4y has quit IRC12:59
*** r3pl4y has joined #openstack-ceilometer13:01
*** thomasem has joined #openstack-ceilometer13:03
*** anand_ts has quit IRC13:05
*** Thumper650 has joined #openstack-ceilometer13:05
Thumper650hi all... have a strange problem13:06
Thumper650I'm runnig seperate control, compute and telemetry nodes13:06
Thumper650every time I issue an ceilomter command on any of them, I get the follwing output13:06
Thumper650root@telemetry-01:~# ceilometer meter-list13:06
Thumper650Unsupported scheme:13:06
Thumper650It seems to be breaking here:13:07
Thumper650+    def get_proxy_url(self):13:07
Thumper650+        scheme = urlutils.urlparse(self.endpoint).scheme13:07
Thumper650+        if scheme == 'https':13:07
Thumper650+            return os.environ.get('https_proxy')13:07
Thumper650+        elif scheme == 'http':13:07
Thumper650+            return os.environ.get('http_proxy')13:07
Thumper650+        msg = 'Unsupported scheme: %s' % scheme13:07
Thumper650+        raise exc.InvalidEndpoint(msg)13:07
Thumper650the reply hints that the scheme variable is empty... but I'm not sure what populates it13:08
*** cmart has quit IRC13:10
*** jmckind has joined #openstack-ceilometer13:11
*** eglynn_ has joined #openstack-ceilometer13:11
*** cmart has joined #openstack-ceilometer13:14
*** joesavak has joined #openstack-ceilometer13:16
*** shakamunyi has joined #openstack-ceilometer13:17
openstackgerritIldiko Vancsa proposed a change to openstack/ceilometer: Fix list of modules not included in auto-gen docs
*** julim has joined #openstack-ceilometer13:18
*** Longgeek has quit IRC13:18
*** Longgeek has joined #openstack-ceilometer13:18
eglynn_Thumper650: check the URLs set in the service catalog for ceilometer13:19
*** Longgeek has quit IRC13:19
*** Longgeek has joined #openstack-ceilometer13:19
*** Longgeek has quit IRC13:19
*** Longgeek_ has joined #openstack-ceilometer13:19
openstackgerritChristian Martinez proposed a change to openstack/ceilometer: Adding alarm list filtering by state and meter
eglynn_Thumper650: $ keystone endpoint-list | grep $(keystone service-list | awk '/ceilometer/ {print $2}')13:21
*** Longgeek_ has quit IRC13:21
eglynn_^^^ there's gotta be a better way than that ;)13:21
Thumper650eglynn: I have the endpoint set to a virtual IP balanced between my two telemetry hosts (that talk to the same DB)13:23
*** Longgeek has joined #openstack-ceilometer13:24
Thumper650hmmm, this may be the result of some weird DNS... brb13:26
*** palar has joined #openstack-ceilometer13:27
*** r3pl4y has quit IRC13:27
*** ddieterly has joined #openstack-ceilometer13:29
*** r3pl4y has joined #openstack-ceilometer13:29
*** alexpilotti has quit IRC13:30
*** `jpg has quit IRC13:32
*** gordc has joined #openstack-ceilometer13:33
Thumper650guess not...13:35
*** fnaval has quit IRC13:38
*** _nadya_ has quit IRC13:38
Thumper650Fixed thanks to eglynn_'s sharp eyes... malformed endpoint publicurl13:46
hoangdoeglynn_: hi eglynn, it's me, the guy want to monitoring the software inside-VM. I have an idea: what if I publish a REST api for our software. Can ceilometer monitors from outside ?13:46
hoangdoeglynn_: is it simplify the work?13:47
eglynn_hoangdo: if the REST API endpoint is callable from outside the VM, then yes it would simplify13:47
eglynn_hoangdo: ... you'd still need to integrate with a ceilometer agent13:47
eglynn_hoangdo: ... write a pollster to call your REST API13:48
hoangdois it similar to central agent?13:48
ildikovhoangdo: here are the curently existing pollsters:
hoangdoildikov: wait, all of those pollsters run on (physical) compute node, right?13:51
ildikovhoangdo: right13:51
*** _nadya_ has joined #openstack-ceilometer13:53
*** jdob has quit IRC13:53
hoangdoildikov: in our case (REST api), should pollsters run on Controller node. I'm not sure we can call api from compute node13:53
boris-42eglynn_ +1 pls lol =)13:53
*** rbowen has joined #openstack-ceilometer13:55
hoangdoildikov: I'm not sure about networking. we are using neutron GRE. And I intend to place an LBaaS in front of REST VM13:56
*** jdob has joined #openstack-ceilometer13:56
*** heyongli has joined #openstack-ceilometer13:56
*** r3pl4y has quit IRC13:57
ildikovhoangdo: hmm, I see13:58
*** ilyashakhat has joined #openstack-ceilometer13:59
*** r3pl4y has joined #openstack-ceilometer13:59
hoangdoildikov: should it run on network node?14:01
openstackgerritA change was merged to openstack/ceilometer-specs: Spec for metering LBaaS
*** promulo has joined #openstack-ceilometer14:02
ildikovhoangdo: it depends on your network toplogy, that where the REST API(s) are available from14:02
hoangdoildikov: REST api will run on a VM. Initially, I intend to assign the VM an public IP.14:04
*** fnaval has joined #openstack-ceilometer14:04
ildikovhoangdo: currently the Ceilometer API supports to send samples to Ceilometer14:08
*** rbowen has quit IRC14:08
ildikovhoangdo: so I was just thinking about if that would be a good solution or not for this case14:09
EmilienMeglynn_: trying to get reviews on #openstack-qa about
EmilienMeglynn_: a bit hard though.14:12
eglynn_EmilienM: ... I'll also add my non-binding $0.0214:13
eglynn_EmilienM: ... hard to get traction on the review?14:13
EmilienMeglynn_: non-binding?14:14
hoangdoildikov: so even I write an agent run inside the node, how can it communicate with the Ceilometer?14:15
ildikovhoangdo: the node is the VM?14:16
eglynn_EmilienM: ... non-binding in the sense of not a core +2 on the review14:16
EmilienMeglynn_: ah14:16
*** Longgeek has quit IRC14:27
*** r3pl4y has quit IRC14:29
*** heyongli has quit IRC14:29
hoangdoildikov: yes a VM14:31
hoangdoildikov: because I want to monitor the software info (rq queue info)14:31
ildikovhoangdo: somehow you have to be able to connect even the VM or something that collects the info from the VM with Ceilometer14:32
ildikovhoangdo: so if the VMs are in a separate network, it will block this for sure14:33
ildikovcmart: hi14:33
*** gordc1 has joined #openstack-ceilometer14:33
*** gordc has quit IRC14:34
cmartI'm working on an alarm management page for horizon.. lblanchard sent some page designs yesterday on the ML that are a guide to follow, but IMHO it needs to be modified14:35
cmartit will be great if you guys (and girls) can give her some feedback about it14:35
ildikovcmart: what would you like to modify?14:36
hoangdoildikov: VMs always on separate network, I guess. Our VMs network controlled by neutron, and I think Ceilometer use other network. So there is no way to poll info from inside VM14:36
hoangdoildikov: blocked! Do you have any suggestion?14:37
ildikovhoangdo: I think the first step should be to figure out how to transmit data between the VMs and Ceilometer (agent or API)14:37
ildikovcmart: I checked the design plan quickly14:39
cmartfor instance the way that alarms are created. For me, it should be a workflow, and it should contemplate the case of "combined alarms" (which is really helpful for me at least).14:39
ildikovcmart: do you want to collect independent opinions or you have ideas that you would like to discuss?14:39
ildikovcmart: a-ha, yes, I agree, I missed that too14:40
*** rwsu has joined #openstack-ceilometer14:40
*** promulo has quit IRC14:40
ildikovcmart: I also do not remember how much it was supported to specify query to the alarms14:40
cmartildikov: I'm kind of new with the alarms stuff, and I think that "alarm experts" should give their feedback around that..14:40
cmartregarding queries, I was working on a bug related to that14:41
cmartcurrently, we have two ways of "querying alarms". With alarm-list --q or query-alarm "a_complex_filter"14:41
ildikovcmart: do you mean the state filtering?14:42
cmartmy fix works around the alarm-list command. It allows you to filter the alarm-list by state and meter_name (which is enougth for now)14:42
cmartfilter by alarm state is like: "Ok, give me all the alarms that are in the state "ok" (like "active alarms")14:43
cmartsmth like: ceilometer alarm-list --q "state=string::insufficient data"14:43
ildikovcmart: a-ha, ok, I remember that one14:44
ildikovcmart: the query-alarm did not solve this issue?14:45
cmartildikov: it has some issues around filtering by meter name (specially on the sqlalchemy driver)14:46
ildikovcmart: hmm, what kind of issues?14:46
cmartthe query:_alarm method was very "generic". It uses a queryTransformer to convert the filter expression into a valid sql statement14:47
cmartin the case of meter, that information is stored within the rule column inside the alarm models..14:48
ildikovcmart: ok, I think I know what you think, the meter name is embedded in the threshold rule14:48
*** matsuhashi has quit IRC14:49
ildikovcmart: ok, I know that issue, it's on the list to add support to these cases too...14:49
ildikovcmart: as for the original question, I'm wondering if it would worth to add an item to the meeting agenda14:49
ildikovcmart: or one more mail on the ML with Ceilometer tag included that hey guys please check14:50
cmartI can do that. I'll forward that email and add the ceilometer tag on the subject14:50
ildikovcmart: I plan to have a deeper look at that doc anyway14:51
ildikovcmart: and also if you already have a list that you would like to discuss here, we can that also14:51
cmartildikov: what I can do is to have a proposal (based on the proposed design and "my thoughts") and share it with you so we can discuss it in the next meeting (or the next)14:53
ildikovcmart: that sounds good to me14:54
cmartildikov: cool! Should I write an etherpad?14:54
ildikovcmart: I think that would be useful14:55
cmartildikov: will do. Tomorrow is the meeting, right?14:56
ildikovcmart: for this week yes14:56
ildikovcmart: I just need one or two mins to clean up the agenda14:56
cmartildikov: OK. I will write that and let you know (so, if you have space, we can add that topic to the agenda:))14:57
hoangdoildikov: hi, I found this post:
hoangdoseems like it's implemented in Havana ?14:59
amalagon hi jd__ I was wondering if I could ask you about the --config-file flag when calling gnocchi-api?15:01
ildikovcmart: ok, I will let you know , if it fits or not15:01
jd__amalagon: sure15:01
amalagonjd__: thanks; so right now I can't get gnocchi-api to work without the --config-file specified; it gives me an error about 'NoneType' object has no attribute 'drivername'15:03
*** jsavak has joined #openstack-ceilometer15:03
*** joesavak has quit IRC15:03
ildikovhoangdo: that should be the API support for sending samples to Ceilometer via its API, what I mentioned earlier15:04
jd__amalagon: where's your configuration file?15:04
*** idegtiarov has quit IRC15:04
amalagonjd__: /etc/gnocchi/15:05
jd__amalagon: ok I see, I'm sending a ptch15:05
amalagonjd__: thanks! er, should I have put gnocchi.conf someplace different?15:06
jd__amalagon: no it's just a bug15:06
openstackgerritIldiko Vancsa proposed a change to openstack/ceilometer: Fix list of modules not included in auto-gen docs
*** cmart has quit IRC15:08
amalagonjd__: cool!15:09
hoangdoildikov: thanks ildikov15:11
ildikovhoangdo: np, I hope it will help15:14
*** Infitialis has quit IRC15:14
amalagonjd__: hey, just to double check (and alert for the newbie question); I pulled the code from the review but gnocchi-api still gives the same error; is there something else I should be doing?15:17
jd__amalagon: no let me check15:19
eglynn_hoangdo: WRT
jd__amalagon: ah did you reinstall it after or something?15:20
jd__amalagon: just to be sure it loads the right file15:20
amalagonjd__: I didn't, sorry about that15:20
eglynn_hoangdo: ... that approach is exactly what I was talking about earlier15:20
jd__amalagon: yeah that might be it :)15:20
amalagonjd__: it's happy now! :D15:21
eglynn_hoangdo: ... *however*, the answer does not address the important issue of how the caller of the API is authenticated15:21
jd__amalagon: cool :)15:21
eglynn_hoangdo: that's why I brought up the whole question of propogating credentials15:21
*** nati_ueno has joined #openstack-ceilometer15:23
*** rbowen has joined #openstack-ceilometer15:24
*** zqfan_home has joined #openstack-ceilometer15:24
*** IvanBerezovskiy has left #openstack-ceilometer15:27
*** r3pl4y has joined #openstack-ceilometer15:31
*** joesavak has joined #openstack-ceilometer15:31
*** jsavak has quit IRC15:34
openstackgerritChinmaya Bharadwaj proposed a change to openstack/ceilometer: VMware: Fixes ceilometer-compute service start failure
*** zqfan_home is now known as zqfan15:37
*** chinmay_ has joined #openstack-ceilometer15:37
*** Thumper650 has quit IRC15:40
*** promulo has joined #openstack-ceilometer15:40
chinmay_@jaypipes : hi15:44
openstackgerritA change was merged to openstack/python-ceilometerclient: Refactor split_by_op and split_by_datatype
openstackgerritOpenStack Proposal Bot proposed a change to openstack/ceilometer: Updated from global requirements
*** rbowen has quit IRC15:49
*** chinmay_ has quit IRC15:51
openstackgerritOpenStack Proposal Bot proposed a change to openstack/python-ceilometerclient: Updated from global requirements
*** _cjones_ has joined #openstack-ceilometer15:55
amalagonhi eglynn_! just want to run something by you - for the create database command in psql, I can do createdb -u USERNAME but not createdb -u root - is it confusing to put the line in the readme as createdb -u USERNAME?15:58
eglynn_amalagon: well that should be fine, I prolly mis-directed you with the reference to root in my comment on gerrit15:58
*** nati_ueno has quit IRC15:59
eglynn_amalagon: i.e. feel free to use "createdb -u USERNAME" instead of "createdb -u root" is that's what actually works15:59
amalagoneglynn_: alright, thanks! just wanted to double check16:00
eglynn_amalagon: np!16:00
*** Ruetobas has quit IRC16:01
*** skelpter has joined #openstack-ceilometer16:01
*** Ruetobas has joined #openstack-ceilometer16:03
*** jsavak has joined #openstack-ceilometer16:06
*** joesavak has quit IRC16:07
*** joesavak has joined #openstack-ceilometer16:08
*** Ruetobas has quit IRC16:08
*** jsavak has quit IRC16:11
*** ddieterl_ has joined #openstack-ceilometer16:12
openstackgerritChristian Berendt proposed a change to openstack/ceilometer: debug level logs should not be translated
*** Ruetobas has joined #openstack-ceilometer16:14
*** underyx is now known as Underyx|off16:14
*** ddieterly has quit IRC16:14
openstackgerritMehdi Abaakouk proposed a change to openstack/ceilometer: Allow to have different DB for alarm and metering
openstackgerritMehdi Abaakouk proposed a change to openstack/ceilometer: Allows to share engine between both sql driver
eglynn_gordc1: o/16:36
*** gordc1 is now known as gordc16:37
gordceglynn_: hey, whatsup?16:37
eglynn_gordc: ... still on for that sql-alchemy call later today with Mike Bayer?16:38
gordceglynn_: yep -- just making notes to the etherpad. it's at 2pm ET right? ~1hr20min from now?16:38
eglynn_gordc: excellent, yeap at 1800UTC ... thank you sir!16:39
gordceglynn_: cool cool. will dial in to conference then.16:40
*** _nadya_ has quit IRC16:40
eglynn_gordc: nice one :)16:40
*** Alexei_987 has quit IRC16:46
*** cmart has joined #openstack-ceilometer16:53
*** joesavak has quit IRC17:03
*** joesavak has joined #openstack-ceilometer17:03
*** niteshselkari has joined #openstack-ceilometer17:05
*** niteshselkari has quit IRC17:12
*** thomasem has quit IRC17:13
*** shakamunyi has quit IRC17:13
*** thomasem has joined #openstack-ceilometer17:13
*** niteshselkari_ has joined #openstack-ceilometer17:15
*** safchain has quit IRC17:17
niteshselkari_hi all17:18
niteshselkari_<eglynn_>: hi eglynn. I had asked this question on ask.openstack.
eglynn_niteshselkari_: yeah I know, it's on my list of things to look into17:21
*** fnaval has quit IRC17:22
openstackgerritCristian A Sanchez proposed a change to openstack/python-ceilometerclient: Make HTTP client aware of no_proxy variable
*** thomasem has quit IRC17:25
openstackgerritChinmaya Bharadwaj proposed a change to openstack/ceilometer: VMware: Fixes ceilometer-compute service start failure
*** thomasem has joined #openstack-ceilometer17:26
niteshselkari_<eglynn>: What approach I can take to find out this...17:26
*** skelpter has quit IRC17:30
*** nati_ueno has joined #openstack-ceilometer17:34
cmartZhiQiang Fan, I don't know what your irc nickname is, but thanks for all the support!17:36
DinaBelovaeglynn_, jd__ btw - what do you think about how will live gnocchi in the future? As a separated project, or part of the ceilometer itself?17:37
zqfancmart, irc nick zqfan17:37
eglynn_DinaBelova: part of ceilometer itself was my assumption17:37
cmartzqfan: Why I didn't think on that?? haha Sorry! And thanks for all your help!17:37
eglynn_DinaBelova: ... the initial separateness enables rapid iteration/innovation17:37
DinaBelovaeglynn_, yeah, ok, I also thought that if this POC will be cool - it should not be one more service :)17:38
DinaBelovayeah, just to be sure17:38
eglynn_DinaBelova: POC == proof of concept?17:38
DinaBelovayes :)17:38
DinaBelovabecause now we're playing there :) but it'll be something more :)17:38
DinaBelovathe overall future of ceilometer :)17:39
eglynn_DinaBelova: ... yeah, so my assumption is that being the core of the v3 API for ceilo, it'll have to come under the ceilometer umbrella17:39
*** harlowja_away is now known as harlowja17:39
DinaBelovawell - yeah, there are too many projects in openstack :D17:39
DinaBelovaalready I mean :)17:40
eglynn_DinaBelova: ... however, it *could* still be realized as a separate service17:40
eglynn_DinaBelova: ... (in the sense of the ceilometer v2 and v3 APIs being hosted in different physical processes)17:40
DinaBelovawell, this should be discussed later I guess - when we'll have the all picture17:40
*** Alexei_987 has joined #openstack-ceilometer17:41
eglynn_DinaBelova: ... but either way, still part of the group of agents/processes/services that we call "ceilometer"17:41
DinaBelovaok, thanks!17:41
DinaBelovacall in 20 mins, btw?17:41
eglynn_DinaBelova: ... yeap, prolly a major agenda item for the mid-cycle meetup17:41
DinaBelovaeglynn_, for sure :)17:41
eglynn_DinaBelova: (if not discussed and decided before then)17:41
eglynn_DinaBelova: ... yep, sql-a call at 1800UTC17:41
DinaBelovaok, cool17:42
*** thomasem_ has joined #openstack-ceilometer17:45
openstackgerritZhiQiang Fan proposed a change to openstack/ceilometer: Update doc for sample config file issue
*** thomasem has quit IRC17:46
*** zqfan has quit IRC17:48
*** _nadya_ has joined #openstack-ceilometer17:52
*** shakayumi has joined #openstack-ceilometer18:08
*** shakayumi has quit IRC18:08
*** _nadya_ has quit IRC18:09
*** shakayumi has joined #openstack-ceilometer18:09
*** shakayumi has quit IRC18:09
*** niteshselkari_ has quit IRC18:12
*** jsavak has joined #openstack-ceilometer18:16
*** joesavak has quit IRC18:16
*** shakayumi has joined #openstack-ceilometer18:18
*** nati_uen_ has joined #openstack-ceilometer18:23
*** nati_ueno has quit IRC18:26
openstackgerritChinmaya Bharadwaj proposed a change to openstack/ceilometer: VMware: Fixes ceilometer-compute service start failure
*** jdob has quit IRC18:28
*** jdob has joined #openstack-ceilometer18:28
*** fnaval has joined #openstack-ceilometer18:35
*** r0j4z0 has quit IRC18:41
*** CAP1089 has joined #openstack-ceilometer18:41
*** CAP1089 is now known as r0j4z018:41
*** promulo has quit IRC18:47
openstackgerritChinmaya Bharadwaj proposed a change to openstack/ceilometer: VMware: Fixes ceilometer-compute service start failure
*** _cjones_ has quit IRC19:00
*** _cjones_ has joined #openstack-ceilometer19:01
openstackgerritChristian Berendt proposed a change to openstack/python-ceilometerclient: Overwrite HelpFormatter constructur to extend argument column
*** ddutta has joined #openstack-ceilometer19:07
eglynn_DinaBelova, gordc: ... so, an useful exercise, or?19:19
gordceglynn_: yeah, definitely. i'll start testing out some of the ideas Mike threw out... see if we can improve what we have.19:23
eglynn_gordc: excellent :)19:23
gordcnice to have an expert to push us in right direction.19:23
eglynn_yeah, my thought exactly19:23
eglynn_... he seems like a pretty constructive guy to me19:24
gordceglynn_: agreed. i wasn't even aware there was a term to the metadata table solution i implemented.19:24
gordcnow i can google how other people have done it.19:25
*** promulo has joined #openstack-ceilometer19:25
eglynn_gordc: not only a term for it, an actual 3 leter acronym! :)19:25
gordcthat's when you know it's a solid idea... when its given an acronym.lol19:26
eglynn_first a three letter acronym ... then a whole O'Reilly book ... then a patent! ;)19:27
eglynn_gordc, DinaBelova: BTW if there's anything I missed or described badly in the short summary on the etherpad, please feel free to hack away at it!19:27
gordcwill do. i'll take a look at it later today... off to another call.19:28
eglynn_gordc: cool, thank you! :)19:28
eglynn_right-o, getting late in my TZ, I'm gonna call it a day19:28
eglynn_... chat tmrw!19:28
*** nati_uen_ has quit IRC19:33
*** ddutta has quit IRC19:36
DinaBelovaeglynn_, yeah, useful really :)19:38
DinaBelovaand Mike has really huge experience here19:38
*** nati_ueno has joined #openstack-ceilometer19:39
DinaBelovaso that's cool to know his PoV19:39
*** palar_ has joined #openstack-ceilometer19:40
*** palar has quit IRC19:43
*** palar_ has quit IRC19:44
*** ddutta has joined #openstack-ceilometer19:47
*** safchain has joined #openstack-ceilometer19:48
*** jsavak has quit IRC19:49
*** joesavak has joined #openstack-ceilometer19:50
*** eglynn_ has quit IRC19:50
*** jsavak has joined #openstack-ceilometer19:51
*** joesavak has quit IRC19:54
*** promulo has quit IRC19:59
*** nati_ueno has quit IRC20:04
*** nati_uen_ has joined #openstack-ceilometer20:07
*** nati_ueno has joined #openstack-ceilometer20:09
*** nati_uen_ has quit IRC20:10
*** ddutta has quit IRC20:15
*** fnaval has quit IRC20:31
*** ddutta has joined #openstack-ceilometer20:39
*** fnaval has joined #openstack-ceilometer20:43
*** ddutta has quit IRC20:44
*** ddutta has joined #openstack-ceilometer20:44
*** cmart has quit IRC20:45
*** claudiub has joined #openstack-ceilometer20:51
*** ddutta has quit IRC20:52
*** harlowja has quit IRC20:54
*** harlowja has joined #openstack-ceilometer20:54
*** jdob has quit IRC21:01
*** _nadya_ has joined #openstack-ceilometer21:09
*** _nadya_ has quit IRC21:14
*** nati_ueno has quit IRC21:26
*** julim has quit IRC21:32
*** jsavak has quit IRC21:44
*** gordc has left #openstack-ceilometer21:51
*** prad has quit IRC22:28
*** `jpg has joined #openstack-ceilometer22:31
*** skelpter has joined #openstack-ceilometer22:41
*** `jpg has quit IRC22:41
*** skelpter has left #openstack-ceilometer22:45
*** shakayumi has quit IRC22:55
*** thomasem_ has quit IRC22:58
*** shakayumi has joined #openstack-ceilometer22:59
*** prad has joined #openstack-ceilometer22:59
*** `jpg has joined #openstack-ceilometer23:01
*** ddieterl_ has quit IRC23:04
*** shakayumi has quit IRC23:15
*** skelpter has joined #openstack-ceilometer23:34
*** skelpter has left #openstack-ceilometer23:41
*** jaypipes has quit IRC23:48

Generated by 2.14.0 by Marius Gedminas - find it at!