Monday, 2014-11-17

*** promulo_ has joined #openstack-ceilometer00:14
*** promulo has quit IRC00:15
*** bklei has joined #openstack-ceilometer00:18
*** bklei has quit IRC00:31
*** ryanpetrello has joined #openstack-ceilometer00:31
*** bklei has joined #openstack-ceilometer00:43
*** ryanpetrello has quit IRC00:47
*** Kennan has quit IRC01:01
*** nosnos has joined #openstack-ceilometer01:01
*** amalagon has joined #openstack-ceilometer01:01
*** ryanpetrello has joined #openstack-ceilometer01:03
*** bklei has quit IRC01:05
*** amalagon has quit IRC01:06
*** bklei has joined #openstack-ceilometer01:06
*** bklei has quit IRC01:10
*** ryanpetrello has quit IRC01:25
*** ryanpetrello has joined #openstack-ceilometer01:26
*** bklei has joined #openstack-ceilometer01:31
*** Yanyanhu has joined #openstack-ceilometer01:36
*** ryanpetrello has quit IRC01:38
*** promulo has joined #openstack-ceilometer01:40
*** promulo_ has quit IRC01:44
*** amalagon has joined #openstack-ceilometer01:54
*** amalagon has quit IRC02:15
*** amalagon has joined #openstack-ceilometer02:16
*** bklei has quit IRC02:31
*** amalagon has quit IRC02:42
*** boris-42 has quit IRC03:07
*** Longgeek has joined #openstack-ceilometer03:28
*** Longgeek has quit IRC03:33
*** nosnos has quit IRC03:49
*** amalagon has joined #openstack-ceilometer03:52
*** amalagon has quit IRC03:56
*** cmyster has quit IRC04:19
*** cmyster has joined #openstack-ceilometer04:23
*** Longgeek has joined #openstack-ceilometer04:44
*** nosnos has joined #openstack-ceilometer04:46
*** Longgeek has quit IRC04:48
*** amalagon has joined #openstack-ceilometer04:53
*** yatin has joined #openstack-ceilometer04:55
*** _nadya_ has joined #openstack-ceilometer05:08
*** yatin has quit IRC05:15
*** bklei has joined #openstack-ceilometer05:31
*** bklei has quit IRC05:36
*** Longgeek has joined #openstack-ceilometer05:37
*** yatin has joined #openstack-ceilometer05:41
*** ishant has joined #openstack-ceilometer05:42
*** nosnos_ has joined #openstack-ceilometer05:50
*** nosnos has quit IRC05:51
*** nosnos_ has quit IRC05:57
*** nosnos has joined #openstack-ceilometer05:59
openstackgerritOpenStack Proposal Bot proposed openstack/ceilometer: Imported Translations from Transifex  https://review.openstack.org/13261906:06
*** _nadya_ has quit IRC06:10
*** Longgeek has quit IRC06:17
*** Longgeek has joined #openstack-ceilometer06:18
*** Longgeek_ has joined #openstack-ceilometer06:18
*** Longgeek has quit IRC06:22
*** ryanpetrello has joined #openstack-ceilometer06:23
*** nosnos_ has joined #openstack-ceilometer06:23
*** nosnos has quit IRC06:23
*** ildikov has quit IRC06:41
*** asalkeld has quit IRC06:42
*** asalkeld has joined #openstack-ceilometer06:42
*** Longgeek_ has quit IRC06:56
*** Longgeek has joined #openstack-ceilometer06:57
*** ryanpetrello has quit IRC07:02
*** eglynn has joined #openstack-ceilometer07:17
*** Longgeek has quit IRC07:27
*** Longgeek has joined #openstack-ceilometer07:28
*** eglynn has quit IRC07:34
*** ildikov has joined #openstack-ceilometer07:39
*** Longgeek_ has joined #openstack-ceilometer07:41
*** safchain has joined #openstack-ceilometer07:44
*** Longgeek has quit IRC07:45
*** eglynn has joined #openstack-ceilometer07:48
openstackgerritMerged openstack/ceilometer: Change event type for identity trust notifications  https://review.openstack.org/13425207:50
llueglynn: has the gnocchi bootstrap time been decided?08:08
*** _nadya_ has joined #openstack-ceilometer08:21
*** ala_ has joined #openstack-ceilometer08:27
openstackgerritBrianLing proposed openstack/ceilometer: For compute resource, expose instance's metadata information in resource_metadata Closes-Bug: 1391778  https://review.openstack.org/13487708:34
*** ishant2 has joined #openstack-ceilometer08:46
*** ishant has quit IRC08:46
*** _nadya_ has quit IRC08:47
*** ifarkas has joined #openstack-ceilometer08:57
openstackgerritJulien Danjou proposed openstack/ceilometer: Remove module not really used by Ceilometer  https://review.openstack.org/13456309:01
openstackgerritJulien Danjou proposed openstack/ceilometer: Switch to oslo.concurrency  https://review.openstack.org/13455209:01
*** IvanBerezovskiy has joined #openstack-ceilometer09:06
*** Kennan has joined #openstack-ceilometer09:07
openstackgerritRomain Soufflet proposed stackforge/gnocchi: Add get_entity method in indexer  https://review.openstack.org/13448509:19
*** ildikov has quit IRC09:19
*** eglynn has quit IRC09:21
*** ildikov has joined #openstack-ceilometer09:25
*** isviridov_away is now known as isviridov09:49
*** ifarkas has quit IRC09:49
*** asalkeld has left #openstack-ceilometer09:56
*** nadya_ has joined #openstack-ceilometer10:16
*** Yanyanhu has quit IRC10:27
*** boris-42 has joined #openstack-ceilometer10:33
*** eglynn has joined #openstack-ceilometer10:40
*** exploreshaifali has joined #openstack-ceilometer10:52
openstackgerritEoghan Glynn proposed stackforge/gnocchi: Minor readability improvements to carbonara  https://review.openstack.org/13462111:05
*** ishant has joined #openstack-ceilometer11:10
*** ishant2 has quit IRC11:11
*** asalkeld has joined #openstack-ceilometer11:18
*** cdent has joined #openstack-ceilometer11:19
*** asalkeld has quit IRC11:43
*** openstackgerrit has quit IRC11:48
*** openstackgerrit has joined #openstack-ceilometer11:49
*** nellysmitt has joined #openstack-ceilometer11:58
*** ildikov has quit IRC11:59
jd__eglynn: I wondered several times about renaming "entity" to something else, WDYT? something like metric or timeserie, not sure12:12
*** ildikov has joined #openstack-ceilometer12:12
eglynnjd__: yeah, fair point, it's almost *too* generic12:13
eglynnjd__: if choosing between metric and timeserie, I'd go with metric12:13
jd__yeah, it was a good choice back then when I was fooling around with Gnocchi and the concepts I was not sure about12:13
jd__now it's clearer how everything works so I wonder12:13
jd__ok I'll keep that in mind, I might do a patch doing some s/// :)12:14
cdentI know that when I first looked at the code the term “entity” made things more confusing12:14
eglynnjd__: so metric seems to me like the higher-level concept (i.e a metric is backed by a set of timeseries of different granularities/retention)12:14
jd__good point12:15
*** jaypipes has joined #openstack-ceilometer12:18
openstackgerritMerged stackforge/gnocchi: Minor readability improvements to carbonara  https://review.openstack.org/13462112:19
*** nadya_ has quit IRC12:22
*** ishant2 has joined #openstack-ceilometer12:26
*** ishant has quit IRC12:26
*** ishant has joined #openstack-ceilometer12:29
*** ishant has quit IRC12:30
*** ishant2 has quit IRC12:30
*** nosnos_ has quit IRC12:39
*** jmatthews has joined #openstack-ceilometer12:40
*** ryanpetrello has joined #openstack-ceilometer12:41
*** ryanpetrello has quit IRC12:54
*** ryanpetrello_ has joined #openstack-ceilometer12:54
*** ryanpetrello_ is now known as ryanpetrello12:54
*** exploreshaifali has quit IRC12:55
*** ifarkas has joined #openstack-ceilometer12:56
*** ddieterly has quit IRC12:59
*** yatin has quit IRC13:04
*** alexpilotti has joined #openstack-ceilometer13:16
openstackgerritJulien Danjou proposed openstack/ceilometer: Remove module not really used by Ceilometer  https://review.openstack.org/13456313:25
openstackgerritJulien Danjou proposed openstack/ceilometer: Switch to oslo.concurrency  https://review.openstack.org/13455213:25
*** nadya_ has joined #openstack-ceilometer13:26
*** ddieterly has joined #openstack-ceilometer13:29
*** ifarkas has quit IRC13:33
*** ddieterly has quit IRC13:34
*** gordc has joined #openstack-ceilometer13:35
*** k4n0_ has quit IRC13:39
openstackgerritJulien Danjou proposed stackforge/gnocchi: rest: allow to have infinite retention in policies  https://review.openstack.org/13450813:40
openstackgerritJulien Danjou proposed openstack/ceilometer: Remove module not really used by Ceilometer  https://review.openstack.org/13456313:42
openstackgerritJulien Danjou proposed openstack/ceilometer: Switch to oslo.concurrency  https://review.openstack.org/13455213:42
openstackgerritLena Novokshonova proposed openstack/ceilometer: Fix order of arguments in assertEquals  https://review.openstack.org/13494013:47
*** ccrouch has joined #openstack-ceilometer13:51
*** ryanpetrello has quit IRC13:53
openstackgerritLena Novokshonova proposed openstack/ceilometer: Fix order of arguments in assertEquals  https://review.openstack.org/13494013:57
*** ryanpetrello has joined #openstack-ceilometer13:59
*** julim has quit IRC14:00
openstackgerritLena Novokshonova proposed openstack/ceilometer: Fix order of arguments in assertEquals  https://review.openstack.org/13494014:00
*** zul has joined #openstack-ceilometer14:00
* cdent switches puters14:08
*** cdent has quit IRC14:08
eglynnjust a reminder that the gnocchi walkthru' doodle poll is closed http://doodle.com/4dutdtq3m7kztysd ... the preferred timelot was 1500UTC today14:18
eglynnhere's the g+ hangout link https://plus.google.com/u/0/events/cts3l8lmi7333friiii4rurr9no14:19
*** ryanpetrello has quit IRC14:19
*** ddieterly has joined #openstack-ceilometer14:22
openstackgerritRomain Soufflet proposed stackforge/gnocchi: Add get_entity method in indexer  https://review.openstack.org/13448514:22
*** ddieterly has quit IRC14:23
*** ddieterly has joined #openstack-ceilometer14:23
*** ddieterly has quit IRC14:25
*** ddieterly has joined #openstack-ceilometer14:26
*** ddieterly has quit IRC14:27
*** ddieterly has joined #openstack-ceilometer14:27
openstackgerritBrianLing proposed openstack/ceilometer: For compute resource, expose instance's metadata information in resource_metadata The related bug id: https://bugs.launchpad.net/ceilometer/+bug/1391778  https://review.openstack.org/13487714:28
*** ryanpetrello has joined #openstack-ceilometer14:36
*** fabiog has joined #openstack-ceilometer14:41
*** cdent has joined #openstack-ceilometer14:42
fabiogcdent: do you have the link for the google hangout presentation, please?14:44
cdentyeah, just a sec, I think I can find it14:44
gordc https://plus.google.com/u/0/events/cts3l8lmi7333friiii4rurr9no14:44
fabioggordc: thanks14:45
cdenttoo late14:45
gordccdent: i had it in chat history :)14:45
gordcif it's wrong, blame eglynn14:45
eglynnfabiog: yep, wot gordc said14:46
openstackgerritJulien Danjou proposed stackforge/gnocchi: Update oslo-incubator  https://review.openstack.org/13495514:47
openstackgerritJulien Danjou proposed stackforge/gnocchi: Import policy from oslo-incubator  https://review.openstack.org/13495614:47
openstackgerritJulien Danjou proposed stackforge/gnocchi: rest: implement policy checks for post measures  https://review.openstack.org/13495714:47
* cdent wonders if the desire to externalize all things is cultural or genetic14:48
eglynncdent: "externalize all things"?14:49
cdentkill monoliths, make everything a plugin14:49
cdent(reacting to response on a comment of mine on https://review.openstack.org/#/c/109367/ )14:49
cdentIn previous environments it was the default and anything to the contrary was considered a bit weird. In this one the opposite often feels true.14:50
cdentSo I'm wondering what the progenitors might be.14:50
gordccdent: solution diversity?14:51
cdentI'm not following you gordc ?14:52
gordccdent: not sure if it's a valid reason, but i think it's because for better or worse, everyone has opinion on how to implement metering/monitoring... making everything pluggable allows that.14:54
cdentAh, I see why I'm confused, I didn't make my point quite right:14:54
cdentI'm saying: why isn't all the stuff which is already pluggable distributed _separately_ from the core.14:54
cdentSince it is already a plugin, it shouldn't be in the core14:54
cdenthaving it in the core makes noise14:54
openstackgerritJulien Danjou proposed stackforge/gnocchi: doc: fix typo in resource type type  https://review.openstack.org/13496214:55
cdentI'm of the camp that says: yes to plugins, but also yes to separate distribution14:55
cdentgood for testing!14:55
gordccdent: ah i see... i guess the intend is that if you put it in core, you don't have to fix it if it breaks... whoever breaks it needs to fix it.14:55
fabiogcdent: but do you want a plugin in stackforge or a Ceilo plugin structure?14:55
fabiogcdent: in Keystone we had a contrib folder for plug-ins that were maintained by the group14:56
gordccdent: plugins are great... because i'm an expert in hbase, mongo, sql, etc... /sarcasm14:56
cdentIdeally the code would just live out there in the world of opensource, neither in ceilo nor stackforge14:56
cdentyou know, there's this thing called the internet and it allows _open_ source14:56
cdent;)14:57
fabiogcdent:: I just suggested tomake the HTTPDispacher sending CADF, so at least there is a certain amount of potential re-use14:57
gordccdent: i think if we can get ceilometer in real world we'll be able to move to a more concise "core" ceilometer...14:58
gordcright now i'm not sure anyone knows what the right 'core' is.14:58
cdentperhaps, but I think the lack of core is part of what makes it hard to get it into real world14:58
gordccdent: agreed... catch-2214:58
cdentI think we need some cold hearted killahs14:59
eglynncdent: are you talking about per-plugin git repos or distributable packages?14:59
*** Longgeek_ has quit IRC14:59
cdentseparate repos14:59
gordccdent: :) write a spec: "Burn down the world"14:59
cdentgordc: I've been writing that spec since I was about 1315:00
* gordc waits for the manifesto.15:00
cdenthttp://manifestopheles.com/manifestos/manifestopheles15:01
eglynncdent: we can have separate repos, but these would be under the ceilometer project umbrella ... not out in the wild interwebs15:01
cdentThat's the crux of the biscuit eglynn. You make that statement categorically, but why?15:01
jd__oye15:01
gordclol we're all missing meeting15:02
eglynnjd__: do you need to press a big green start button?15:02
jd__I did15:02
jd__I AM LIVE ON THE INTERNET15:02
gordci'm goig to be late...15:02
gordccarry on15:02
eglynnjd__: hmmm ... "The live video broadcast will start soon"15:02
jd__refresh?15:03
cdentrefresh worked15:03
eglynnjd__: cool, got it :)15:03
jd__I got 2 viewers15:03
jd__I can invite people if you want to join and chat15:04
jd__let me know15:04
jd__otherwise I'll be reading on IRC15:04
eglynnjd__: which ever is most convenient for multi-task with15:04
fabiogjd__: hi15:04
nadya_hi all!15:04
*** bklei has joined #openstack-ceilometer15:04
jd__IRC being async it's going to be easier I guess15:05
*** bklei has quit IRC15:05
eglynnjd__: cool15:05
*** bklei has joined #openstack-ceilometer15:05
eglynncdent: hold that thought, after the hangout15:05
* cdent nods15:05
cdentno rush, in fact it's probably better _written_15:05
cdent(thus inclusive)15:05
* cdent has decided that jd__ is the long lost 4th member of the beastie bosy15:06
jd__everyone's hearing me? just to be sure15:07
cdentlost you15:07
*** fnaval has joined #openstack-ceilometer15:07
jd__I lost wifi for a sec :/15:07
cdentback now15:07
eglynnback15:07
*** julim has joined #openstack-ceilometer15:08
eglynnjd__: hey15:08
jd__yes?15:08
jd__ok I guess there's a 2 minutes lag as usual15:08
*** bklei has quit IRC15:12
*** rbak has joined #openstack-ceilometer15:13
fabiogjd__: is the rest api consuming the same format produced by Ceilo Dispatcher or get the original format?15:13
*** bklei has joined #openstack-ceilometer15:13
cdentobject dispatch--15:14
eglynnfabiog: original format? ... do you mean the ceilometer classical sample format?15:14
fabiogeglynn: I mean the notifications published by the services without massaging into samples15:15
eglynnfabiog: gnocchi measures are much more distilled than samples15:15
eglynndown again?15:15
fabiogyep15:16
ildikovyeap15:16
* cdent nods15:16
gordci think jd__ is gone. he dropped on our internal chat as well.15:16
*** exploreshaifali has joined #openstack-ceilometer15:16
eglynnfabiog: samples include lots of metadata, much closer to the original notification payload15:16
eglynnfabiog: gnocchi measures are feather light by comparison15:16
eglynnfabiog: just a timestamp plus value15:16
fabiogeglynn: but who does the conversion, is it done in the API or external to the API15:17
eglynnfabiog: currently done in a ceilometer dispatcher15:17
eglynnfabiog: so external to gnocchi right now15:17
cdentwhich seems a much better way15:17
fabiogeglynn: ok, thanks15:17
cdentkeeps gnocchi doing what gnocchi does well, only15:17
eglynnfabiog: as it happens that ceilometer dispatchers lives in the gnocchi repo (proposed as a patch to same)15:18
jd__sorry looks I lost my connection again15:18
jd__I should have stayed home15:18
jd__:-)15:18
eglynnfabiog: but conceptually upstream from the gnocchi API15:18
eglynnjd__: office wifi?15:18
cdenteglynn: are there plans to put it in ceilometer instead?15:18
jd__yes, never had any issue so far but that's the right moment to start15:19
ildikovI think it's simply Monday...15:19
eglynnjd__: is there an option to use a wired connection15:19
eglynn?15:19
jd__eglynn: not on my Mac :)15:19
eglynncdent: all options are on the table re. the final resting place of all this code, for the mo' treated as a gnocchi patch purely for convenience15:20
cdentcool, seems like the dispatcher ought to go with the rest of the dispatchers, but gnocchi itself would benefit from staying apart15:20
eglynnpoints and timespan are just different ways of expressing the same idea15:21
openstackgerritZhiQiang Fan proposed openstack/ceilometer: Do not raise exception when libvirt returns None for memory usage  https://review.openstack.org/13496615:21
eglynnusually an entity is created in the context of a resource15:24
amalagonis the indexer.create_resource being changed to indexer.create_entity?15:25
fabiogjd__: why do you need to link the policy with the entity? Isn't expressed as instance.vcpu 1week ...15:25
eglynnamalagon: former creates a resource, latter creates just an entity15:25
amalagonso even in create_entity indexer.create_resource would be used?15:26
eglynnfabiog: the policy determines the granularity and retention for the entity15:26
eglynnamalagon: the resource may be pre-existing15:27
eglynnamalagon: an entity captures data for just one aspect of the resource15:27
eglynnamalagon: in general many entities may be associated with a single resource15:27
fabiogok thanks15:27
amalagonI see, thanks!15:27
openstackgerritMerged openstack/ceilometer: Skip to poll and publish when no resources found  https://review.openstack.org/13216915:29
*** jmatthews has quit IRC15:29
cdentbest exception name ever15:30
eglynnjd__: referencing that carbonara exception in the REST layer is prolly a layer-violation, or?15:31
jd__yes15:31
jd__definitely :)15:31
jd__we should change that15:31
eglynncool15:31
eglynnjd__: how about switching that dict in the get_measures response to a list?15:33
jd__I thought I did it but I will15:33
eglynnjd__: a-ha it does now, you're right15:34
jd__is my code not up to date?15:34
jd__yeah M-x revert-buffer15:34
jd__:D15:34
eglynnjd__: yeah, you've changed it now on trunk15:35
fabiogso in a value received as measure for disk.read.bytes it does mean that disk is resource and read.bytes is entity and then the value 5000 and timestamp is the measure ... is that right?15:36
eglynnfabiog: yep15:37
fabiogeglynn: but why do you need an entity id? isn't that the case that all these "sample" names are unique?15:37
fabiogmeaning disk.read.bytes15:37
eglynnfabiog: so that the entity can be referred decoupled from the resource15:38
eglynnfabiog: but within the context of a resource, it can be referred to by name15:38
fabiogeglynn: I was wondering if you coud this in a reactive way ... I save the data as disk.read.bytes 5000 T115:39
fabiogand then I distill the fact that it refers to the disk resource15:39
fabiogand then to the read.byte entity15:39
eglynnfabiog: "reactive" ==> do you mean create the entity as a side-effect of POSTing the first measure?15:39
fabiogeglynn: afterwards so I will release client fast and then process the measure to decouple it into pieces15:40
nadya_eglynn: one entity can be referenced by only one resource, right?15:40
eglynnfabiog: the problem with implicitly creating the entity from a measure is specifying the archive policy15:41
eglynnnadya_: in practice, yes15:41
eglynnnadya_: but that was strictly not required by the original schema15:41
fabiogeglynn: that is the part I really don't understand ... What is the level of granularity you can write a policy against? disk. disk.read and disk.read.bytes?15:42
eglynnfabiog: archice policies can be set per-entity15:42
fabiogeglynn: so you can have one for disk.read.bytes. Can you also have a generic one for disk?15:43
fabiogmeaning at the resource level?15:43
eglynnfabiog: one acrhive policy per entity15:43
eglynnfabiog: an entity is aspect of an *individual* resource15:44
eglynnfabiog: so for a single resource, different entities can have different archive policies15:44
eglynnfabiog: e.g. to keep cpu_util measures for less time than some other instance metric15:44
fabiogsure, but basically is to create a table of unique "sample" names and then associate to those a time-to-live15:45
eglynnfabiog: gnocchi allows the entities of the same name to have different archive policies for different resources15:46
fabiogeglynn: I am trying to understand if we could blindly accept measures without having to do too much work and batch wirte them and afterward process them to add the intelligence required15:46
eglynnfabiog: e.g. keep metrics for webserver instances for longer than dev instances15:46
eglynnfabiog: as mentioned above, blindly accepting measures for asynch processing would require some way of specifying the archive policy15:47
openstackgerritlitong01 proposed openstack/ceilometer-specs: http dispatcher spec  https://review.openstack.org/10936715:47
eglynnfabiog: we would need for example some notion of the default archive policy for a particular named entity15:47
fabiogeglynn: let continue after the presentation I am falling behind :-)15:48
eglynnjd__: so probably not a pressing need for a mongodb indexer driver, as the volume of data would be relatively small and RDB-friendly15:48
eglynnfabiog: fair enough15:48
* jd__ nods15:48
*** zul has quit IRC15:49
eglynnsilence again?15:49
nadya_eglynn: one question from me here https://review.openstack.org/#/c/98798/65/gnocchi/ceilometer/resources/instance.py . It's about metadata in general actually15:49
*** zul has joined #openstack-ceilometer15:50
eglynnnadya_: "If we want to have a link to Heat stack (or Sahara cluster, or Trove cluster) we will manually add corresponding params here? Or the solution is still is being discussed?"15:50
nadya_eglynn: everything is ok for me, stream is alive15:50
eglynnnadya_: the core idea is to avoid just blindly storing the free-form metadata from all these resource types15:51
eglynnnadya_: instead resource-specific attributes that we need to store are *strongly* typed on the resource representation in the indexer15:52
eglynnnadya_: ... we don't need to store resource-specific attributes, then there is a catch-all "generic" resource15:52
eglynnjd__: yeah, mean15:54
nadya_eglynn: yes, I understand an idea, but filtering by heat_stack looks very essential request15:55
nadya_eglynn: maybe it should be some mechanism to "add" metadata user is interested in?15:55
*** rwsu has joined #openstack-ceilometer15:56
fabiogjd__:  so Carbonara is not required for storage systems that are already TS (e.g. Influx)?15:56
eglynnnadya_: yes, similar to the server_group added as a attribute of the instance resource (to represent the heat autoscaling group)15:56
eglynnfabiog: no15:56
eglynnfabiog: only for the swift and file based storage drivers15:56
fabiogeglynn: makes sense15:56
eglynnfabiog: (that's what I meant by the layer-violation comment earlier, carbonara shouldn't be exposed to the REST layer)15:57
openstackgerritPradeep Kilambi proposed openstack/ceilometer: Support to capture network services create notifications  https://review.openstack.org/12168615:58
jd__fabiog: right15:59
jd__questions?15:59
jd__(sorry I didn't read the whole backlog, thanks eglynn for taking care :)15:59
cdentSeems nicely structured. +116:00
eglynnjd__: good to mention the tests run against mysql and postgresql?16:00
eglynn(integration test stylee)16:00
fabiogwhat db you support for the indexer16:00
openstackgerritIgor Degtiarov proposed openstack/ceilometer: Clean unused tables from mongodb and db2  https://review.openstack.org/13256116:00
jd__fabiog: you can look at the documentation at http://gnocchi.rtfd.org/ to learn more from the API I guess16:00
shardyeglynn: Hi!16:00
eglynnjd__: I missed the last part of the hangout so you may have said already ... good to mention the tests are run against mysql and postgresql? (integration test stylee)16:00
shardyeglynn: when you get a moment, can we chat about https://review.openstack.org/#/c/132198/?16:00
jd__yeah I talked about the scenario usage in the test16:01
eglynnshardy: hey, sure we're just finishing up a g+ hangout16:01
shardyasalkeld is querying if we can solve it in ceilometer instead of Heat, I'm not sure atm16:01
jd__we gate against mysql and postgresql16:01
nadya_jd__: maybe it should be some mechanism to "add" metadata user is interested in? F.e. for filtering by heat stack or sahara cluster16:01
shardyeglynn: Ok, np, ping me whenever's convenient, thanks! :)16:01
eglynnshardy: cool, will do16:01
jd__nadya_: it's very hard to filter on unstructured data so we want to avoid that16:01
amalagonjd__: what are the next steps for gnocchi? or is it pretty complete now?16:02
jd__nadya_: we already added server_group for Heat for example16:02
eglynnnadya_: currently we require that the resource-specific attribute is explicitly modelled in the resource representation16:02
* nadya_ thanks jd__ and eglynn!16:03
jd__amalagon: policy, more drivers, and tracking changes in resources from the top of my head :)16:03
amalagonthx!16:04
jd__moar questions?16:04
cdentcan it serve coffee?16:04
jd__no16:04
cdentbummer16:04
jd__NOT YET16:04
amalagonthe factorizing of carbonara is pretty new; did the performance go up a lot after doing that?16:05
eglynnjd__: what's your thinking on cross-entity batching of post_measures?16:05
cdentPATCHES ACCEPTED16:05
jd__amalagon: not on the factorizing itself, but it's now multithreaded so it should be faster16:05
nadya_alarms? are we gonna support this?16:05
eglynn(i.e. allowing datapoints for multiple entities to be submitted in a single call)16:05
nadya_sorry if it's already discussed somewhere....16:05
openstackgerritZhiQiang Fan proposed openstack/ceilometer: Add timeout to all http requests  https://review.openstack.org/13297416:05
jd__nadya_: yes, we need to adapt ceilometer-alarm to use that new schema16:06
eglynnnadya_: yes, the alarming feature will have to be migrated to the v3 API (based on gnocchi)16:06
nadya_cool16:06
eglynnnadya_: (that was the motivation for adding the instance resource server_group attribute)16:06
fabiogthanks jd__16:07
amalagonjd__: how did you feel about the selectable granularity parameter?16:07
eglynnnadya_: (i.e. for Heat autoscaling alarms)16:07
jd__amalagon: I need to work on that too yeah16:07
eglynnjd__: I've got an ancient patch for that that I could ressurect16:07
nadya_eglynn: will take a look on this more carefully16:07
eglynn(i.e. selectable granularity in the API layer)16:07
jd__eglynn: go ahead, I've not even started :)16:08
eglynncool16:08
eglynnthanks for presenting the hangout jd__!16:08
jd__you're welcome16:09
amalagonthanks jd__!16:11
*** david-lyle_afk is now known as david-lyle16:11
ildikovjd__: tnx!16:11
nadya_jd__: Thanks!16:12
*** ildikov has quit IRC16:17
openstackgerritJulien Danjou proposed stackforge/gnocchi: storage: merge coordination and carbonara  https://review.openstack.org/13499916:18
openstackgerritJulien Danjou proposed stackforge/gnocchi: Fix and test the NullStorage driver  https://review.openstack.org/13500016:18
*** ala_ has quit IRC16:19
*** sdake has joined #openstack-ceilometer16:20
*** sdake has quit IRC16:20
*** sdake has joined #openstack-ceilometer16:20
eglynncdent: re. your earlier comments on splitting out plugins, moving to out-of-tree16:21
eglynncdent: yes, we can have multiple repos16:21
eglynncdent: but those repos would need also to have an upstream16:21
eglynncdent: i.e. a sustainable community of code review, maintainership, release mgmt etc.16:21
eglynncdent: so they either come under our ubrella, or some ither umbrella that we can rely on16:22
eglynnsome *other16:23
openstackgerritSrinivas Sakhamuri proposed openstack/ceilometer: Internal error with period overflow  https://review.openstack.org/13441516:23
eglynnso we do not want to create orphened repos, IMO16:23
cdentwhy to this: "but those repos would need also to have an upstream"16:24
cdentBasically I'm advocating that ceilometer should provide the framework for a set of activities16:24
cdentand then the people who want specific activities should own the implementaiton16:24
openstackgerritSrinivas Sakhamuri proposed openstack/ceilometer: Internal error with period overflow  https://review.openstack.org/13441516:24
cdent(e.g. storage in hbase, or cassandra)16:24
cdent(or dispatch via some mechanism)16:24
cdentMy original statement was trying to discern the source of the notion that there needs to be an umbrella. Why the centralization?16:25
cdentan orphaned repo is a repo containing code that people don't care about16:25
eglynncdent: "people who want specific activities should own the implementaiton" ... do you mean the operators that want to say deploy on hbase should the implementation?16:25
cdentwhich is fine, that means it doesn't matter16:25
cdentand when code doesn't matter we cetainly dont' want it in a core16:25
cdentsure16:26
cdentscope is too wide16:26
eglynnso, as I said before, there are candidates for moving out-of-tree16:26
eglynnspecifically things that difficult impossible to CI upstream16:26
eglynnvsphere inspector / IPMI node manager stuff springs to mind16:27
cdentYeah, so I'll say again: "My original statement was trying to discern the source of the notion that there needs to be an umbrella. Why the centralization?"16:27
cdentI'm not concerned, at this time, with the actual details of reality, I'm interested in how the current reality came about (and ultimately, from that, know how to change it)16:27
fabiogcdent: we could take a olso approach: like ceilometer-vsphere ... ceilometer-ipmi and so on16:28
eglynncdent: note that I said "they either come under our umbrella, or some *other* umbrella that we can rely on"16:28
cdentAll "these big tent" conversations are the result of an entirely broken model of open source, probably the results of corporate lawyers with too much time on their hand, and not enough anarchists or something16:28
fabiogcdent: one repo for these non-core projects16:28
eglynn(with spelling corrections this time)16:28
cdentfabiog: why?16:28
fabiogcdent: because you want to give the ability of people interested in that topic to contribute and or monitor the status16:29
fabiogs/of/to16:29
cdentpeople contribute to small open source projects all over the internet just by using the internet16:29
cdentthey don't need branding16:29
fabiogbut customers do16:30
cdentI disagree, customers need distros16:30
eglynncdent: so consumers of openstack artifacts naturally want to be assured that the maintainership of those artifacts is sustainable16:30
cdentand the job of a distro is to aggregate16:30
cdentand provide assurance16:30
fabiogcdent: a customer wants to know that the stuff is getting is backed by a community and organization16:31
cdentthat is: if the distro wishes to make money they patronize maintainership16:31
fabiogcdent: if you add things that are only specific to you they may perceive vendor lock in16:31
cdentfabiog I'm not really sure that's true, they want stuff that works16:31
eglynncdent: distro and operators already "patronize" most of the community16:31
cdenteglynn: yes, of course, what I'm saying is that patronage could have more diverse granularity16:32
fabiogcdent: agreed, but if to make it work is 60% proprietary they will be reluctant16:32
cdentrather than in this giant thing called openstack16:32
cdentAll I was trying to discern here is if there is a cultural bias in place of some sort.16:33
cdentAnd this conversation is making it pretty clear that there is.16:33
cdentWhich is not a problem, it is just good information to have.16:33
cdentthe coarse and potentially offensive way of summarizing my observation is "Dear god, openstack is _really_ enterprisey"16:35
cdentsorry "enterprisey™"16:35
eglynn"cultural bias" and "enterprise-y" is pretty loaded TBH16:35
cdententerprisey, yes16:35
cdentbut cultural bias , how?16:36
cdentit just says "there is a culture here" and "there is a culture over there"16:36
cdentthat's true everywhere people gather16:36
cdentand each culture will have perspective16:36
eglynnclear negative connotation, no?16:36
*** amalagon has quit IRC16:37
cdentPerhaps, but it is unavoidable: Everywhere people gather people will have a perspective on their surroundings which is different from other people, no?16:38
*** nadya_ has quit IRC16:38
eglynnit's clear that the incentives/motivations driving the openstack community are different to many other opensource communities16:38
fabiogeglynn: I would send you a follow-up e-mail for the discussion around measure storing in batches16:39
eglynna higher proporition of contributors are "patronized" by the big distributors and operators16:39
fabiogeglynn: what is the best e-mail address16:39
eglynnfabiog: thank you sir!16:39
eglynnfabiog: eglynn@redhat.com16:39
fabiogeglynn: thaks16:39
*** r-daneel has joined #openstack-ceilometer16:39
eglynnso you can read the result as "bias", or simply as the result of the incentives/drivers in operation16:40
cdentwe seem to have strayed quite far from my original query, which is great in some ways, but to take it back:16:40
cdentThere appears to be a cultural bias _against_ small pieces loosely joined.16:41
*** ifarkas has joined #openstack-ceilometer16:41
cdentI don't reckon there can be any operational difference betwen "bias" and "results of incentives/drivers". Surely that's the same thing? In society my biases are developed out of the incentives/drivers I experience.16:42
eglynnIMO "bias" carries a connotation of prejudice and/or unfairness16:44
openstackgerritJulien Danjou proposed stackforge/gnocchi: Import policy from oslo-incubator  https://review.openstack.org/13495616:44
openstackgerritJulien Danjou proposed stackforge/gnocchi: rest: implement policy checks for post measures  https://review.openstack.org/13495716:44
openstackgerritJulien Danjou proposed stackforge/gnocchi: Update oslo-incubator  https://review.openstack.org/13495516:44
cdentAh, that's interesting.16:44
eglynnthe OED tends to agree16:44
cdentI think of it more in terms of "biased in favor of, biased against"16:45
cdentSo the quote is "there was evidence of bias against black applicants"16:46
cdentso I'm saying "there is evidence of bias against small pieces loosely joined"16:46
cdentfrom my perspective (as someone who llikes small pieces) I'd say yeah, it's prejudicial16:47
cdentbut that'd be my opinion16:47
cdentIt's very hard for me to tell if you're engaging on this from some kind of intellectual interest or because you have some other goal in mind.16:47
eglynncdent: huh?16:49
cdentwell, are you hoping to change my perception, or we just chattin'?16:49
eglynnneither16:50
cdentwhat is it then?16:50
eglynnI was just explaining my view of the reality of the situation in openstack16:50
cdentbah to reality!16:50
cdentreality is the lamest constraint ever, especially in the software world!16:51
cdenttotally fungible16:51
eglynnfungible ... in the sense of being replaceable by another identical thing?16:54
cdenthere on earth, eglynn, can you take a gander at https://review.openstack.org/#/c/134840/ (redis in packstack) and help me figure out what I've done wrong?16:54
cdent(in legal doctrine fungible is not so exact)16:55
*** tasdomas` is now known as tasdomas16:59
*** amalagon has joined #openstack-ceilometer16:59
eglynncdent: I'll take a look after 1:117:00
cdent17:00
*** rwsu has quit IRC17:03
eglynncdent: ^^^ I suspect the failing RH CI on that patch requires puppet-redis to be past of the openstack-puppet-module package in advance17:07
cdentI'm not worried about that yet: it fails in local testing with the redis branch in use, following packstack devel instructions17:08
*** _cjones_ has joined #openstack-ceilometer17:14
*** _cjones_ has quit IRC17:15
*** _cjones_ has joined #openstack-ceilometer17:15
*** rwsu has joined #openstack-ceilometer17:16
*** rwsu has quit IRC17:18
eglynnsileht: can you look at https://review.openstack.org/132092 (tooz patch I'd like to get before tooz 0.9.0 is cut)17:21
*** rwsu has joined #openstack-ceilometer17:21
*** ccrouch has quit IRC17:27
*** amalagon has quit IRC17:37
*** fabiog has quit IRC17:39
*** harlowja_away is now known as harlowja17:41
*** amalagon has joined #openstack-ceilometer17:50
*** bklei has quit IRC17:54
*** bklei has joined #openstack-ceilometer17:54
*** bklei has quit IRC17:58
*** bklei has joined #openstack-ceilometer17:59
*** bklei has quit IRC18:00
*** bklei has joined #openstack-ceilometer18:03
*** bklei has quit IRC18:03
*** _cjones_ has quit IRC18:05
*** _cjones_ has joined #openstack-ceilometer18:05
silehteglynn, looks good18:07
eglynnsileht: thank you sir!18:08
cdentEmilienM: are you packstack and openstack puppet modules savvy?18:09
gordccdent: i think he might be on a plane right now... that or he might already have landed and is shocked by the snow.18:11
cdenti'm flying early wednesday morning, to snow18:11
cdentI miss snow.18:11
gordci live in an apartment so i'm fine with snow... if i was at my parents house, then my opinion changes.18:12
*** amalagon has quit IRC18:21
*** amalagon has joined #openstack-ceilometer18:21
*** ccrouch has joined #openstack-ceilometer18:26
*** nellysmitt has quit IRC18:27
*** dnalezyt has joined #openstack-ceilometer18:28
openstackgerritlitong01 proposed openstack/ceilometer: add http dispatcher  https://review.openstack.org/10985318:29
*** ildikov has joined #openstack-ceilometer18:30
*** nadya_ has joined #openstack-ceilometer18:40
*** zul has quit IRC18:48
*** sbfox has joined #openstack-ceilometer19:01
*** nadya_ has quit IRC19:03
*** nadya_ has joined #openstack-ceilometer19:34
*** sbfox has quit IRC19:34
*** zul has joined #openstack-ceilometer19:35
*** sbfox has joined #openstack-ceilometer19:39
*** nadya_ has quit IRC19:42
*** sbfox has quit IRC19:57
*** sbfox has joined #openstack-ceilometer20:02
*** ccrouch has quit IRC20:04
*** ifarkas has quit IRC20:34
*** exploreshaifali has quit IRC20:45
*** openstackgerrit has quit IRC20:49
*** openstackgerrit has joined #openstack-ceilometer20:49
harlowjaeglynn http://lists.openstack.org/pipermail/openstack-dev/2014-November/050811.html if u want to add anything special :)21:16
* eglynn looks21:16
eglynnharlowja: cool, thanks for raising this21:19
harlowjaeglynn np :)21:20
harlowjagotta start somewhere :)21:20
*** sbfox has quit IRC21:23
*** sbfox has joined #openstack-ceilometer21:24
*** exploreshaifali has joined #openstack-ceilometer21:30
*** julim has quit IRC21:30
cdentharlowja, eglynn that thread reminds me: is there a plan pending for sentinel support in tooz?21:36
*** alexpilotti has quit IRC21:39
*** prad has joined #openstack-ceilometer21:40
*** promulo has quit IRC21:43
*** cdent has quit IRC21:44
*** promulo has joined #openstack-ceilometer21:46
*** safchain has quit IRC21:52
*** asalkeld has joined #openstack-ceilometer21:53
*** alexpilotti has joined #openstack-ceilometer21:55
*** safchain has joined #openstack-ceilometer22:05
harlowjawhen i can get a CI testable sentinel :)22:10
* harlowja doesn't trust manual stuff so much22:10
*** admin0 has joined #openstack-ceilometer22:16
*** exploreshaifali has quit IRC22:20
*** fnaval_ has joined #openstack-ceilometer22:33
*** fnaval has quit IRC22:35
*** asalkeld has quit IRC22:47
*** alexpilotti has quit IRC22:52
*** ryanpetrello has quit IRC23:00
*** asalkeld has joined #openstack-ceilometer23:00
*** alexpilotti has joined #openstack-ceilometer23:02
*** sbfox has quit IRC23:03
*** admin0 has quit IRC23:04
*** r-daneel has quit IRC23:14
*** rbak_ has joined #openstack-ceilometer23:30
*** zul has quit IRC23:31
*** rbak_ has quit IRC23:32
*** ddieterly has quit IRC23:33
*** rbak has quit IRC23:33
*** sbfox has joined #openstack-ceilometer23:36

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!