Wednesday, 2014-04-30

*** raymondr has joined #openstack-ceilometer00:16
*** nati_ueno has joined #openstack-ceilometer00:20
*** nati_uen_ has quit IRC00:23
*** fnaval has quit IRC00:26
*** thomasem has joined #openstack-ceilometer00:29
*** nsaje has quit IRC00:52
openstackgerritliusheng proposed a change to openstack/ceilometer: Support direct alarm_evaluator service db access
*** nsaje has joined #openstack-ceilometer00:55
*** nati_ueno has quit IRC01:01
*** nati_ueno has joined #openstack-ceilometer01:04
*** liusheng has joined #openstack-ceilometer01:13
*** fnaval has joined #openstack-ceilometer01:16
liushengHi all, may I ask for help getting some your thoughts about bp: ?01:19
liushengthanks :)01:20
*** _cjones_ has quit IRC01:24
*** _cjones_ has joined #openstack-ceilometer01:25
*** _cjones_ has quit IRC01:30
*** Daviey has quit IRC01:33
*** nosnos has joined #openstack-ceilometer01:35
*** raymondr has quit IRC01:59
*** gordc has quit IRC02:00
*** thomasem has quit IRC02:08
*** raymondr has joined #openstack-ceilometer02:10
*** raymondr has quit IRC02:20
openstackgerritOpenStack Proposal Bot proposed a change to openstack/ceilometer: Updated from global requirements
openstackgerritOpenStack Proposal Bot proposed a change to openstack/pycadf: Updated from global requirements
openstackgerritOpenStack Proposal Bot proposed a change to openstack/python-ceilometerclient: Updated from global requirements
*** matsuhashi has quit IRC02:56
*** changbl has joined #openstack-ceilometer02:56
*** matsuhashi has joined #openstack-ceilometer02:57
*** alexpilotti has quit IRC03:01
*** alexpilotti has joined #openstack-ceilometer03:03
*** alexpilotti has quit IRC03:04
*** nati_ueno has quit IRC03:10
*** nati_ueno has joined #openstack-ceilometer03:11
*** liusheng has quit IRC03:21
*** liusheng has joined #openstack-ceilometer03:21
*** raymondr has joined #openstack-ceilometer03:42
*** nati_ueno has quit IRC03:50
*** raymondr has quit IRC03:52
*** raymondr has joined #openstack-ceilometer03:53
*** raymondr_ has joined #openstack-ceilometer03:55
*** raymondr has quit IRC03:57
*** raymondr_ has quit IRC03:59
*** shakamunyi has quit IRC04:05
*** matsuhashi has quit IRC04:10
*** fnaval has quit IRC04:18
*** rdmcnair has joined #openstack-ceilometer04:21
*** nati_ueno has joined #openstack-ceilometer04:24
*** fnaval has joined #openstack-ceilometer04:25
*** nosnos has quit IRC04:26
*** nati_ueno has quit IRC04:45
*** nati_ueno has joined #openstack-ceilometer04:47
*** alexpilotti has joined #openstack-ceilometer04:51
*** alexpilotti has quit IRC04:56
*** ildikov has quit IRC05:03
*** matsuhashi has joined #openstack-ceilometer05:04
*** rdmcnair has quit IRC05:13
*** nosnos has joined #openstack-ceilometer05:16
*** nosnos has quit IRC05:22
*** nosnos has joined #openstack-ceilometer05:23
*** matsuhashi has quit IRC05:30
*** matsuhashi has joined #openstack-ceilometer05:30
*** matsuhashi has quit IRC05:36
*** matsuhashi has joined #openstack-ceilometer05:36
*** dperaza1 has quit IRC05:38
*** ildikov has joined #openstack-ceilometer05:49
*** zul has quit IRC05:59
*** promulo has quit IRC06:02
openstackgerritOpenStack Proposal Bot proposed a change to openstack/ceilometer: Imported Translations from Transifex
*** zul has joined #openstack-ceilometer06:14
*** dperaza has joined #openstack-ceilometer06:16
*** _nadya_ has joined #openstack-ceilometer06:31
*** alexpilotti has joined #openstack-ceilometer06:39
*** alexpilotti has quit IRC06:45
*** eoutin has joined #openstack-ceilometer07:04
*** eoutin has quit IRC07:04
*** eoutin has joined #openstack-ceilometer07:07
*** matsuhashi has quit IRC07:08
*** matsuhashi has joined #openstack-ceilometer07:11
*** matsuhashi has quit IRC07:17
*** ekarlso has joined #openstack-ceilometer07:17
*** matsuhashi has joined #openstack-ceilometer07:17
*** _nadya_ has quit IRC07:18
*** _nadya_ has joined #openstack-ceilometer07:21
*** Daviey has joined #openstack-ceilometer07:22
*** _nadya_ has quit IRC07:24
*** nati_ueno has quit IRC07:29
*** _nadya_ has joined #openstack-ceilometer07:30
*** fnaval has quit IRC07:32
*** nacim has joined #openstack-ceilometer07:37
*** zigo_ is now known as zigo07:55
*** idegtiarov has joined #openstack-ceilometer07:58
*** ildikov_ has joined #openstack-ceilometer08:04
*** ildikov has quit IRC08:04
*** eglynn has joined #openstack-ceilometer08:35
*** eglynn has quit IRC08:48
*** eglynn has joined #openstack-ceilometer08:50
openstackgerritZhiQiang Fan proposed a change to openstack/python-ceilometerclient: Avoid empty alarm id when call alarm-update
openstackgerritliusheng proposed a change to openstack/ceilometer: Improve the query_to_kwargs method
DinaBelovaeglynn, o/09:42
eglynnDinaBelova: yo09:42
DinaBelovaI wanted to point your attention to one of the changes proposed now to the Ceilometer
DinaBelovaLiu Sheng has fixed lots of moments for now..09:43
openstackgerritliusheng proposed a change to openstack/ceilometer: Improve the query_to_kwargs method
DinaBelovabut the thing is with the not approved BP09:43
DinaBelovaso he can't move further I guess09:44
eglynnDinaBelova: I saw that patch, but held off commenting because there's a summit session scheduled to discuss this and other changes09:44
DinaBelovaheh, ok, good to know!09:44
DinaBelovaok, thanks!09:45
eglynnDinaBelova: ... I'll comment on gerrit also09:45
DinaBelovaeglynn, I just was lost there :)09:45
DinaBelovathanks for the direction)09:45
*** denis_makogon has joined #openstack-ceilometer09:50
openstackgerritSylvain Afchain proposed a change to openstack/ceilometer: Opencontrail network statistics driver
*** alexpilotti has joined #openstack-ceilometer10:11
DinaBelovaeglynn, about your comments to the - I don't really think that list -> tuple will bring much here.... as in lots of [] usages then it might be .append used...10:19
DinaBelovaand it won't work great with the tuple10:19
DinaBelovadon't you think so?10:19
*** nosnos has quit IRC10:21
DinaBelovaeglynn, so that will need additional checks in the code later in the method request workflow10:22
eglynnDinaBelova: yeah I guess append not working great with tuple was the point10:22
eglynnDinaBelova: if someone comes along and modifies a method that currently doesn't mutate the mutable list then that would fail fast as the default param is now a tuple10:22
DinaBelovaso possibly these several lines are ok, but keep code without the possible bugs10:22
eglynnDinaBelova: .. a-ha, I think I see ... you're concerned about the case where unit test does currently exercise the default case?10:22
eglynnDinaBelova: s/does/doesn't/10:23
DinaBelovayes, and these too10:23
eglynnDinaBelova: ... k, stick that thought in gerrit for posterity and I'll reply there10:23
DinaBelovaeglynn, replied)10:27
*** nosnos has joined #openstack-ceilometer10:29
*** admin0 has joined #openstack-ceilometer10:37
*** openstackgerrit has quit IRC10:51
shardyeglynn: hey, fyi added a response to your comment on
eglynnshardy: ... thanks looking now10:53
shardyeglynn: IMO it would be a better pattern if ceilometer created the trust when the alarm is created, be interested to hear your thoughts10:53
eglynnshardy: ... /me is confused about how ceilometer could create the trust10:55
eglynnshardy: ... I thought the delegation flow was *from* heat *to* ceilo10:55
eglynnshardy: ... i.e. not ivce versa10:55
shardyeglynn: no, ceilometer needs to impersonate the stack owning user, whose token is used when we create the alarm10:55
shardyso ceilometer has all the information required to create the trust between the ceilometer service user and the stack owner, during the creation of the alrm10:56
shardyalarm even10:56
shardythat is the same pattern we use creating a trust for autoscaling actions now in heat10:56
eglynnshardy: ... a-ha of course, I see, so only a valid token is required to create the trust10:56
shardyeglynn: yes10:56
eglynnshardy: ... yeah in that case I think it does make a lot more sense for ceilo to handle that10:57
shardyif we were to do that it would actually remove the requirement for heat impersonation, because we'd see an alarm from the stack-owner, not ceilometer10:57
shardyor rather the alarm action would appear to be from the stack owner10:57
eglynnshardy: ... yeap, and totally avoids the leakage of ceilo user identity into heat config, right?10:58
shardyit is more work on the ceilometer side, but it seems atm to make more sense10:58
eglynnshardy: ... so win, win10:58
shardyexactly, cos you already know what your service user details are10:58
eglynnshardy: yeap, agreed ... so that heat patch is -2'd pending the corresponding ceilo change, or?10:58
eglynntherve: ^^^ relevant chatter :)10:59
shardyit does raise the interesting question of how users know which services are going to take their token and impersonate them, but I guess that's a bigger issue for discussion ;)10:59
shardyeglynn: I've just -1'd it pending discussion with therve10:59
shardyand yourself obviously ;)10:59
eglynnshardy: yeah, I guess it's kinda implicit that once you release a token into the wild, the receiver can do what it likes with it11:00
shardyI'm not sure what the interface should look like, but I guess we need a flag when creating the alarm which says "create a trust"11:00
shardythen that is used for subsequent alarm action notifications11:00
eglynnshardy: ... doesn't therve's initial version embed 'trust+' in the alarm action URL scheme?11:01
shardyit's a bit different to what we have now, but it has the nice advantage that nobody can steal the signed URL and trigger arbitrary actions anymore11:02
eglynnshardy: ... so on alarm creation with some action including 'trust+http(s)://' (or on alarm update if 'trust+' not seen previously for this alarm) then the trust is created at that point?11:03
eglynnshardy: ... also do we require one trust per alarm action, or one per alarm, or just one per alarm-owner?11:03
shardyeglynn: yeah, maybe that's enough, I guess we pass trust:<URL> and ceilometer has to add the trust-id@ bit11:03
eglynnshardy: yeah, that would probably suffice11:04
shardyeglynn: the trust is between the alarm owner and the ceilometer service user, so in theory only the latter11:04
shardyI guess it may be easier to just create one per alarm though and store it when the alarm is created11:05
eglynnshardy: k, so a little bit of extra logic might be required to tear down the trust when the last alarm for that user is deleted11:05
shardyOne slight complexity is trusts requires you to delegate a role, so we require all stack owners to have the "heat_stack_owner" role, which is delegated by default11:06
eglynnshardy: does that distinguished role have to be identified when the trust is created?11:07
shardyceilometer would need a config option which specifies the list of roles that are delegated, probably with heat_stack_owner being the default, given that we're probably the only user for this interface atm?11:07
shardyeglynn: yes11:07
shardyit's a list of roles, which must be at least one, and the roles must be assigned to the user delegating them11:08
eglynnshardy: ... k, so in a sense we're getting identity leakage in the opposite direction (heat -> ceilo)11:08
eglynnshardy: ... unless this list of roles is embedded in the alarm action URL somehow?11:08
shardywell it's really dependent on the deployers rbac policies, we just added that role e.g to devstack to make things work11:09
shardymaybe we need a globall role like trust_ok or something11:10
shardyso users get explicitly added to some role which means delegation is allowed for them11:10
shardyor there could be a new ceilometer specific role, ceilometer_alarm_owner or something, but that starts getting cumbersome for users/deployers11:11
eglynnshardy: ... hmmm wouldn't using a single global role (trust_ok) be kinda removing one degree of freedom from the whole trusts mechanism?11:11
eglynnshardy: ... and hardcoding ceilo to always use ceilometer_alarm_owner role for the trust would seem overly restrictive too11:12
shardyeglynn: Yeah I guess it would, I'm really trying to establish sane defaults for development, I would expect real production deployments to have customized policies for most services which enforces separation11:13
shardyeglynn: the thing is, the role to be delegated is really a deployer decision, because they have visibility of the policies, and the user doesn't11:13
shardyso requiring them to provide a role when creating the alarm probably doesn't make sense11:14
eglynnshardy: ... presumably also the ceilometer service user would have to have been already granted this role to be delegated?11:14
eglynn(... so that impacts on deployment mechanisms like puppet/packstack/foreman/fuel etc.)11:14
shardyeglynn: no, only the stack owner needs to have the role11:14
shardythen the role is delegated via the trust to the ceilometer service user (who does not need to have the role)11:15
shardybut whatever role is used must exist, and be assigned to the user creating the stack11:15
eglynnshardy: ... a-ha ok, got it backwards there for a second11:15
shardyso it does impact deployment mechanisms to an extent11:15
shardy(hence me bouncing ideas around which avoid a default proliferation of new roles)11:16
eglynnshardy: ... so the rule must (a) exist, and (b) the heat RBAC rules must be defined to restrict the autoscaling trigger endpoints to callers assigned/delegated this role?11:17
shardyeglynn: the role must exist, and the heat RBAC rules *could* be defined such that we allow e.g the ceilometer callback to send a resource a signal, but not delete a stack11:18
shardye.g we use another role "heat_stack_user" which is assigned to all in-instance users, so we limit the API surface they can access11:19
*** denis_makogon has left #openstack-ceilometer11:19
eglynnshardy: ... what's the diff between the heat_stack_owner role mentioned above and the heat_stack_user role referenced in the policy.json?11:21
eglynnshardy: ... so I was kinda expecting the delegated role to be really minimal11:22
shardyheat_stack_owner is the role delegated to the heat service user for doing autoscaling actions via a trust11:22
shardyheat_stack_user is an "untrusted" role we assign to users created by heat which are associated with in-instance credentials11:23
shardye.g wait conditions11:23
shardyso the delegated role is really minimal by default11:23
shardybut for "real" deployments, it might be a list of roles required to access certain services, e.g nova11:24
eglynnshardy: ... k, so delegation of the heat_stack_owner role makes the ceilo alarm notifier capable of calling back on the autoscaling trigger endpoints11:24
eglynn... but nothing more "destructive" than that?11:24
shardyeglynn: yeah that's basically the idea11:25
shardywith config file options such that deployers can customize what the delegated token can do depending on their environment11:25
eglynnshardy: cool, I was confused by the lack of reference to heat_stack_owner in the out-of-the-box policy.json11:26
shardyE.g by default, ceilometer probably only needs to be able to do this one action:11:26
shardyeglynn: Yeah heat_stack_owner is really a dummy role, and alias for "whatever roles needed to launch stuff for autoscaling"11:26
shardybecause the trust is used inside heat to make API calls, primarily to other services, not heat11:27
eglynnshardy: ... one last dumb question, how is the segregation between stacks handled if there's just a single role involved for all autoscaling signals?11:28
shardyeglynn: that is a good question actually :)11:29
shardyeglynn: right now, we create a user associated with the pre-signed URL we pass to ceilometer, which is in a special domain specific to heat, in a project specific to the stack11:29
shardy(assuming the new for icehouse instance-users stuff is being used)11:30
shardyso that pre-signed URL can only ever access that one stack11:30
shardyand the roles associated with it mean it has heat_stack_user, so the API surface is already limited as mentioned above11:31
eglynnshardy: cool, but the trust mechanism replaces the old pre-signed URL approach, or?11:31
shardyif we move to the trust scheme, we lose some of that separation, as the ceilo service user has a trust scoped to a project, with a role11:31
shardybut not any separation between stacks11:31
shardythat is probably OK, as the ceilometer user is "trusted", unlike the agents in the instances11:32
shardyand it's basically the same as the stack-owner can do, e.g they can send signals to any stacks in their project if they wish11:32
eglynnshardy: a-ha, k, so the lifecycle of the trust is really bound to the project ... as opposed, as opposed to the individual user or alarm11:32
shardyYeah that's one of the reasons we moved to the more granular stack-domain-user model for in-instance credentials11:33
shardyprobably removing the risk of replay attacks is more important than the ceilometer service sending an alarm to the wrong stack11:34
shardyIf we really need that separation, the solution would be for heat to create a domain-isolated user, and for ceilometer to impersonate that user not the stack owner11:35
shardythen heat "sees" ceilometer as another in-instance agent via the API11:35
eglynnshardy: cool, the veil is being lifted from mine eyes ... again ;)11:37
eglynnshardy: so to sum up ... what really makes the basic mechanism work is your earlier statement11:37
eglynn"the role is delegated via the trust to the ceilometer service user (who does not need to have the role)"11:38
eglynn ... i.e. the fact that a trust can be created by userA to *acquire* some role privilege from *another* userB11:38
eglynn... as long as userA has been passed a token by userB11:38
shardyeglynn: exactly11:38
eglynn... /me was more thinking of the act of trust creation being the point at which privilege was *delegated* from userB to userA11:39
eglynn(as opposed to being grabbed by userA from userB)11:39
therveshardy, Catching up11:40
eglynnshardy: cool, that discussion clarified loads for me, thanks!11:40
shardyeglynn: well it's really the latter, as the trust must be created by userB, explicitly allowing userA to impersonate them with a subset of their roles11:40
shardyit's just that in this case, the service (heat or ceilometer) is creating that trust for them11:40
shardy(using their token, passed to the service)11:41
eglynnyeah, in this case the ceilo user (userA) would be creating the trust for the stack owner (userB) in order to be able to impersonate userB when signalling the AS endpoint11:44
eglynn"/me was more thinking..." == "/me was previously incorrectly thinking..."11:44
shardyeglynn: not quite, the keystone API call would be made by userB (or rather by the ceilometer service using their token)11:45
shardyI'm talking about keystone identities not which entity makes the API request11:45
therveshardy, So, if ceilo creates the trust, it needs to know about the roles somehow, right?11:47
eglynnshardy: yeap, I think we're saying the same thing pretty much (modulo that terminology distinction between keystone identity and the entity making the API request)11:47
shardytherve: yeah, or there needs to be a new ceilometer_alarm_owner role or something11:47
*** admin0 has quit IRC11:48
eglynntherve: ... or if that role needs to be controllable from the heat side, an alternative would be to embed it in the alarm action URl somehow11:48
shardytherve: I'm wondering if there's a way for us to reuse a stack-domain-user, with the heat_stack_user role, e.g the same as we currently do for the AWS signed URLs, then not only is the scope limited by the trust, it's also limited to a specific stack11:48
shardythe problem with that is the alarm is created by the stack-owner, not the stack-domain-user associated with e.g the ScalingPolicy11:49
shardyeglynn: yeah, that may end up being the most flexible approach11:49
therveshardy, Well, we should trust ceilometer, no?11:49
shardytherve: yeah, that's pretty much what I said above, it's probably much better to trust ceilomter with a project-wide trust than the current solution where any leak of the URL is susceptible to replay attacks11:51
therveHum okay.11:52
therveshardy, Sorry, but doesn't that contradict " if there's a way for us to reuse a stack-domain-user" ?11:52
shardytherve: I'm just wondering if there's any way to do both, because currently when we pass a pre-signed URL to ceilometer, it cannot be used to access any other stack than the one owning the alarm11:53
shardywhereas with the trusts scheme it could11:53
therveAh I see11:53
shardyminor issue, I should probably stop thinking out loud :)11:54
*** fnaval has joined #openstack-ceilometer11:54
therveshardy, So you're saying using trust is better, but trust scoped to a project would be better11:54
shardytherve: the trust is already scoped to a project, but it could be used to send alarms to any stack in the project11:54
therveScoped to a stack11:54
eglynnyeap that's what I was getting at earlier with the stack segregation question, scoped to a single stack would be better surely?11:54
shardyif possible, it would be super-great if we could make it scoped to the stack, and driven by trusts11:55
therveWe would need to pass the credentials of the domain user to ceilo11:55
therveI think?11:56
therveNo we would impersonate him11:56
shardyyeah, or go back to the current solution and create the trust and pass it to ceilometer11:56
eglynnso with ceilo creating trust as suggested, for there to an exploit ceilo would have to leak both (a) the AS trigger URL and (b) the original stack owner's token11:56
eglynn(... instead of just leaking the pre-signed URL as before)11:56
eglynn... and that's not any more insecure that heat itself creating the trusts11:57
shardyeglynn: yes, or leak the AS trigger URL, the trust ID, and the ceilometer service user credentials ;)11:57
shardyIf that happens then I think all bets are off ;)11:57
therveshardy, If we just change heat patch to create the trust for the stack domain user, that would work, no?11:58
therveWithout changing anything in the trust notifier in ceilo11:58
shardytherve: yup, but the conversation started out with shouldn't ceilometer be creating the trust not heat11:58
eglynn... and just to confirm, there's no stack segregation going on *regardless* of whomever (heat or ceilo) creates the trust?11:59
therveshardy, So what's the benefit of that?11:59
eglynntherve: no need for heat to know the ceilo user ID11:59
therveThat's a small deployment issue, but okay11:59
eglynn(as per the comments on )12:00
therveshardy, So the problem is that we would need to create the alarm as the domain user?12:00
therveThat would break assumptions of regular templates logic12:00
shardytherve: it seems like maybe the opportunity for additional separation may trump the slightly cleaner deployment pattern of ceilometer creating the trust12:00
shardytherve: yeah you're right, but we could create the trust between the stack-domain-user and the ceilometer user, and pass the trust12:01
shardyso to wrap up this long conversation, I am wrong ;)12:02
*** matsuhashi has quit IRC12:02
*** admin0 has joined #openstack-ceilometer12:02
therveWell not really :). But I think we can fix everything in Heat12:02
*** matsuhashi has joined #openstack-ceilometer12:02
shardytherve: yeah, it's been good to have this discussion anyway to bounce the various ideas around12:02
shardyeglynn: thanks for taking the time to go through this12:03
*** matsuhashi has quit IRC12:03
eglynnshardy: ... well thank you for being gentle in your explanations, all much clearer to me now!12:03
shardyeglynn: ha, cool, hopefully between us we now know how it should work :)12:04
*** liusheng has quit IRC12:06
*** eglynn-lunch has joined #openstack-ceilometer12:07
*** eglynn has quit IRC12:07
*** nosnos has quit IRC12:09
*** _nadya_ has quit IRC12:13
*** _nadya_ has joined #openstack-ceilometer12:14
*** jdob has joined #openstack-ceilometer12:17
*** eoutin has quit IRC12:17
*** erecio has joined #openstack-ceilometer12:20
*** eoutin has joined #openstack-ceilometer12:21
*** reazem has quit IRC12:27
*** reazem has joined #openstack-ceilometer12:28
*** erecio_1 has joined #openstack-ceilometer12:36
*** erecio has quit IRC12:38
*** ityaptin has quit IRC12:44
*** julim has joined #openstack-ceilometer12:49
*** ityaptin has joined #openstack-ceilometer12:54
*** eglynn has joined #openstack-ceilometer12:58
*** inc0 has joined #openstack-ceilometer13:01
*** bada has quit IRC13:05
*** eoutin has quit IRC13:06
*** rdmcnair has joined #openstack-ceilometer13:09
*** eglynn has quit IRC13:11
*** reazem has quit IRC13:15
*** joesavak has joined #openstack-ceilometer13:16
*** reazem has joined #openstack-ceilometer13:18
*** thomasem has joined #openstack-ceilometer13:19
*** _nadya_ has quit IRC13:28
*** rdmcnair has quit IRC13:29
*** eoutin has joined #openstack-ceilometer13:29
*** mengxd has joined #openstack-ceilometer13:29
*** fnaval has quit IRC13:30
*** inc0 has quit IRC13:31
*** eoutin has quit IRC13:33
*** erecio_1 has quit IRC13:39
*** mengxd has quit IRC13:42
*** eglynn has joined #openstack-ceilometer13:44
*** gordc has joined #openstack-ceilometer13:44
*** jmckind has joined #openstack-ceilometer13:50
*** _nadya_ has joined #openstack-ceilometer13:52
*** eglynn-lunch has quit IRC13:53
*** sdake_ has quit IRC13:53
*** openstackgerrit has joined #openstack-ceilometer13:55
*** erecio_1 has joined #openstack-ceilometer13:57
*** nealph has quit IRC13:58
*** fnaval has joined #openstack-ceilometer13:59
*** prad_ has joined #openstack-ceilometer14:05
ityaptineglynn: Hi! Sorry for the late answer.14:08
ityaptineglynn: About user and project. Usually these tables are used little and contain little data. Also I forgot to change user or project) I think we can set user and project as it happens with resource_id from exists list.14:08
eglynnityaptin: np!14:08
ityaptineglynn: We started to test logs because this approach was simple and universal for different backends. Also I am trying to use python profiler but have not representative results yet.14:09
eglynnityaptin: so the sample timestamp and recorded_at values stored in the DB are insufficient14:10
eglynnityaptin: ... because you want to separate out the AMQP lag for the metering message and the storage latency within the collector, correct?14:10
eglynnityaptin: cool, and yeah the variance in the user_id and project_id is not a big deal14:12
eglynnityaptin: ... /me was thinking though that a more realistic traffic mix14:13
eglynnityaptin: ... (i.e. a mix of meters names, not just instance, as well as variance in user_id and project_id) would have higher "fidelity" to real deployments14:14
eglynnityaptin: ... but probably wouldn't alter the results a great deal14:14
ityaptineglynn: I think, for performance of collector it has not any differences.14:16
eglynnityaptin: ... yeap, very marginal at most14:17
eglynnjd__, ildikov_, gordc, llu, nsaje: just wondering if y'all had a chance to check the design summit schedule, for conflicts with other other commitments etc.?14:23
jd__that sounds like a good procrastination before the week end, thanks eglynn14:24
jd__I'm going to make my summit schedule right now14:24
eglynnjd__: LOL ... displacement activity is my speciality ;)14:24
gordc9am is nap time for me. i'm skipping your session jd__14:26
gordcluckily my hotel this time isn't a 1hr train ride like hong kong so early sessions are a bit better.14:27
jd__eglynn: ok looks like you avoided to conflict with the import sessions that are breaks and lunches, so that LGTM :D14:29
*** raymondr has joined #openstack-ceilometer14:29
eglynnjd__: ... yeap I avoided that banana skin just about14:30
*** nati_ueno has joined #openstack-ceilometer14:31
ildikov_gordc: I know that one hour feeling very well... :S :)14:34
ildikov_eglynn: fine with me14:34
*** erecio_1 has quit IRC14:37
*** ildikov_ has quit IRC14:44
*** ildikov_ has joined #openstack-ceilometer14:44
*** prad_ has left #openstack-ceilometer14:52
*** prad_ has joined #openstack-ceilometer14:53
*** _nadya_ has quit IRC14:54
*** fabio has joined #openstack-ceilometer15:07
*** eglynn is now known as eglynn-afk15:09
*** ildikov_ has quit IRC15:13
*** fnaval has quit IRC15:22
*** erecio_1 has joined #openstack-ceilometer15:22
*** fnaval has joined #openstack-ceilometer15:22
*** fnaval has quit IRC15:27
*** fnaval has joined #openstack-ceilometer15:29
*** sdake_ has joined #openstack-ceilometer15:32
*** sdake_ has joined #openstack-ceilometer15:32
*** _nadya_ has joined #openstack-ceilometer15:32
*** fabio has quit IRC15:32
*** _cjones_ has joined #openstack-ceilometer15:37
*** _cjones_ has quit IRC15:42
*** _cjones_ has joined #openstack-ceilometer15:43
*** rdmcnair has joined #openstack-ceilometer15:43
*** admin0 has quit IRC15:43
*** eglynn-afk has quit IRC15:45
*** vrovachev has quit IRC15:45
*** admin0 has joined #openstack-ceilometer15:46
*** erecio_1 has quit IRC15:46
openstackgerritIonut Artarisi proposed a change to openstack/ceilometer: reconnect to mongodb on connection failure
*** admin0 has left #openstack-ceilometer15:55
*** erecio_1 has joined #openstack-ceilometer15:59
*** jsavak has joined #openstack-ceilometer16:00
*** Ruetobas has quit IRC16:01
*** packet has joined #openstack-ceilometer16:01
*** joesavak has quit IRC16:02
*** gordc has quit IRC16:02
*** gordc1 has joined #openstack-ceilometer16:02
*** packet has quit IRC16:03
*** Ruetobas has joined #openstack-ceilometer16:03
*** sdake_ has quit IRC16:03
*** packet has joined #openstack-ceilometer16:05
*** nacim has quit IRC16:05
*** packet has quit IRC16:05
*** packet has joined #openstack-ceilometer16:06
*** sdake_ has joined #openstack-ceilometer16:07
*** Ruetobas has quit IRC16:07
openstackgerritIgor Degtiarov proposed a change to openstack/ceilometer: Implement record_events method for HBase
*** _cjones_ has quit IRC16:12
*** _cjones_ has joined #openstack-ceilometer16:13
*** Ruetobas has joined #openstack-ceilometer16:13
*** idegtiarov has quit IRC16:14
*** eglynn has joined #openstack-ceilometer16:16
*** nati_ueno has quit IRC16:16
*** _cjones_ has quit IRC16:17
*** sdake_ has quit IRC16:29
*** erecio_1 has quit IRC16:31
*** joesavak has joined #openstack-ceilometer16:43
*** jsavak has quit IRC16:46
*** jmckind has quit IRC16:51
*** erecio_1 has joined #openstack-ceilometer16:55
*** gordc has joined #openstack-ceilometer17:00
*** nati_ueno has joined #openstack-ceilometer17:00
*** nati_ueno has quit IRC17:01
nsajeeglynn: no problem for me!17:01
*** gordc1 has quit IRC17:01
*** _nadya_ has quit IRC17:02
*** nati_ueno has joined #openstack-ceilometer17:03
*** bada has joined #openstack-ceilometer17:13
*** bada has quit IRC17:14
*** Ju has joined #openstack-ceilometer17:14
*** Alexei_987 has joined #openstack-ceilometer17:18
*** Ju has quit IRC17:19
*** Ju has joined #openstack-ceilometer17:21
eglynnnsaje: cool :)17:25
*** nati_ueno has quit IRC17:30
*** nati_ueno has joined #openstack-ceilometer17:30
*** nati_ueno has quit IRC17:31
*** nati_ueno has joined #openstack-ceilometer17:31
*** _cjones_ has joined #openstack-ceilometer17:43
*** erecio_1 has quit IRC17:45
*** jmckind has joined #openstack-ceilometer17:50
*** jmckind has quit IRC17:56
*** jmckind has joined #openstack-ceilometer17:56
*** nati_ueno has quit IRC18:07
*** nati_ueno has joined #openstack-ceilometer18:07
*** ildikov has joined #openstack-ceilometer18:12
*** promulo has joined #openstack-ceilometer18:16
*** nati_ueno has quit IRC18:20
*** nati_ueno has joined #openstack-ceilometer18:21
*** erecio has joined #openstack-ceilometer18:27
*** promulo has quit IRC18:40
*** _nadya_ has joined #openstack-ceilometer18:45
*** eglynn has quit IRC18:46
*** nati_ueno has quit IRC18:47
*** nati_ueno has joined #openstack-ceilometer18:48
*** nati_ueno has quit IRC18:49
*** dperaza has quit IRC18:49
*** nati_ueno has joined #openstack-ceilometer18:51
*** dperaza has joined #openstack-ceilometer18:55
*** sdake_ has joined #openstack-ceilometer18:59
*** promulo has joined #openstack-ceilometer19:07
gordcthomasem: ping19:09
thomasemgordc: pong19:09
thomasemWhat's the story? :)19:09
gordchey Thomas, i was going to start looking at this:
gordcdo you know an easy way to build a massive events db using devstack?19:10
thomasemgordc: That's how I generated the crazy large events DB earlier19:11
thomasemWhen I found that bug19:11
gordcthomasem: cool ok. i'll take a look at that.19:11
thomasemThat repo probably hasn't been updated in a while, but it essentially lets you inject massive amounts of test data into the Events table using Ceilometer models.19:11
thomasemAnother way would be to script a bunch of create/delete commands on DevStack19:12
gordcthomasem: exactly what i want. i'll give the repo a try to see if still works.19:12
thomasemAwesome, sounds great! :)19:13
*** nati_ueno has quit IRC19:25
*** eglynn has joined #openstack-ceilometer19:40
*** _nadya_ has quit IRC19:53
*** nati_ueno has joined #openstack-ceilometer20:00
*** nati_ueno has quit IRC20:04
-openstackstatus- NOTICE: the gate is backed up due to broken nodepool images, fix in progress (eta 22:00 utc)20:24
*** ChanServ changes topic to "the gate is backed up due to broken nodepool images, fix in progress (eta 22:00 utc)"20:24
*** _nadya_ has joined #openstack-ceilometer20:24
*** nati_ueno has joined #openstack-ceilometer20:25
*** sdake_ has quit IRC20:39
*** shakayumi has joined #openstack-ceilometer20:47
*** shakayumi has quit IRC20:47
*** erecio has quit IRC20:58
*** jdob has quit IRC20:59
*** _nadya_ has quit IRC21:03
*** sdake_ has joined #openstack-ceilometer21:03
*** thomasem has quit IRC21:04
*** thomasem has joined #openstack-ceilometer21:05
*** thomasem has quit IRC21:10
*** shakayumi has joined #openstack-ceilometer21:15
*** shakayumi has quit IRC21:15
*** reazem has quit IRC21:33
*** jmckind has quit IRC21:44
*** promulo has quit IRC21:46
*** eglynn has quit IRC21:54
*** raymondr has quit IRC21:56
*** gordc has quit IRC21:57
*** shardy is now known as shardy_afk22:01
*** nati_ueno has quit IRC22:15
*** nati_ueno has joined #openstack-ceilometer22:28
*** fnaval has quit IRC22:34
*** fnaval has joined #openstack-ceilometer22:36
*** prad_ has quit IRC22:37
*** nati_ueno has quit IRC22:43
*** nati_ueno has joined #openstack-ceilometer22:45
*** fnaval has quit IRC22:47
*** rdmcnair has quit IRC22:49
*** joesavak has quit IRC23:40
*** nati_ueno has quit IRC23:48
*** nati_ueno has joined #openstack-ceilometer23:48
*** nati_ueno has quit IRC23:54

Generated by 2.14.0 by Marius Gedminas - find it at!