| *** raymondr has joined #openstack-ceilometer | 00:16 | |
| *** nati_ueno has joined #openstack-ceilometer | 00:20 | |
| *** nati_uen_ has quit IRC | 00:23 | |
| *** fnaval has quit IRC | 00:26 | |
| *** thomasem has joined #openstack-ceilometer | 00:29 | |
| *** nsaje has quit IRC | 00:52 | |
| openstackgerrit | liusheng proposed a change to openstack/ceilometer: Support direct alarm_evaluator service db access https://review.openstack.org/89756 | 00:54 |
|---|---|---|
| *** nsaje has joined #openstack-ceilometer | 00:55 | |
| *** nati_ueno has quit IRC | 01:01 | |
| *** nati_ueno has joined #openstack-ceilometer | 01:04 | |
| *** liusheng has joined #openstack-ceilometer | 01:13 | |
| *** fnaval has joined #openstack-ceilometer | 01:16 | |
| liusheng | Hi all, may I ask for help getting some your thoughts about bp:https://blueprints.launchpad.net/ceilometer/+spec/direct-alarm-evaluator-db-access ? | 01:19 |
| liusheng | thanks :) | 01:20 |
| *** _cjones_ has quit IRC | 01:24 | |
| *** _cjones_ has joined #openstack-ceilometer | 01:25 | |
| *** _cjones_ has quit IRC | 01:30 | |
| *** Daviey has quit IRC | 01:33 | |
| *** nosnos has joined #openstack-ceilometer | 01:35 | |
| *** raymondr has quit IRC | 01:59 | |
| *** gordc has quit IRC | 02:00 | |
| *** thomasem has quit IRC | 02:08 | |
| *** raymondr has joined #openstack-ceilometer | 02:10 | |
| *** raymondr has quit IRC | 02:20 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/ceilometer: Updated from global requirements https://review.openstack.org/88714 | 02:38 |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/pycadf: Updated from global requirements https://review.openstack.org/88729 | 02:46 |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/python-ceilometerclient: Updated from global requirements https://review.openstack.org/91238 | 02:46 |
| *** matsuhashi has quit IRC | 02:56 | |
| *** changbl has joined #openstack-ceilometer | 02:56 | |
| *** matsuhashi has joined #openstack-ceilometer | 02:57 | |
| *** alexpilotti has quit IRC | 03:01 | |
| *** alexpilotti has joined #openstack-ceilometer | 03:03 | |
| *** alexpilotti has quit IRC | 03:04 | |
| *** nati_ueno has quit IRC | 03:10 | |
| *** nati_ueno has joined #openstack-ceilometer | 03:11 | |
| *** liusheng has quit IRC | 03:21 | |
| *** liusheng has joined #openstack-ceilometer | 03:21 | |
| *** raymondr has joined #openstack-ceilometer | 03:42 | |
| *** nati_ueno has quit IRC | 03:50 | |
| *** raymondr has quit IRC | 03:52 | |
| *** raymondr has joined #openstack-ceilometer | 03:53 | |
| *** raymondr_ has joined #openstack-ceilometer | 03:55 | |
| *** raymondr has quit IRC | 03:57 | |
| *** raymondr_ has quit IRC | 03:59 | |
| *** shakamunyi has quit IRC | 04:05 | |
| *** matsuhashi has quit IRC | 04:10 | |
| *** fnaval has quit IRC | 04:18 | |
| *** rdmcnair has joined #openstack-ceilometer | 04:21 | |
| *** nati_ueno has joined #openstack-ceilometer | 04:24 | |
| *** fnaval has joined #openstack-ceilometer | 04:25 | |
| *** nosnos has quit IRC | 04:26 | |
| *** nati_ueno has quit IRC | 04:45 | |
| *** nati_ueno has joined #openstack-ceilometer | 04:47 | |
| *** alexpilotti has joined #openstack-ceilometer | 04:51 | |
| *** alexpilotti has quit IRC | 04:56 | |
| *** ildikov has quit IRC | 05:03 | |
| *** matsuhashi has joined #openstack-ceilometer | 05:04 | |
| *** rdmcnair has quit IRC | 05:13 | |
| *** nosnos has joined #openstack-ceilometer | 05:16 | |
| *** nosnos has quit IRC | 05:22 | |
| *** nosnos has joined #openstack-ceilometer | 05:23 | |
| *** matsuhashi has quit IRC | 05:30 | |
| *** matsuhashi has joined #openstack-ceilometer | 05:30 | |
| *** matsuhashi has quit IRC | 05:36 | |
| *** matsuhashi has joined #openstack-ceilometer | 05:36 | |
| *** dperaza1 has quit IRC | 05:38 | |
| *** ildikov has joined #openstack-ceilometer | 05:49 | |
| *** zul has quit IRC | 05:59 | |
| *** promulo has quit IRC | 06:02 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/ceilometer: Imported Translations from Transifex https://review.openstack.org/88506 | 06:03 |
| *** zul has joined #openstack-ceilometer | 06:14 | |
| *** dperaza has joined #openstack-ceilometer | 06:16 | |
| *** _nadya_ has joined #openstack-ceilometer | 06:31 | |
| *** alexpilotti has joined #openstack-ceilometer | 06:39 | |
| *** alexpilotti has quit IRC | 06:45 | |
| *** eoutin has joined #openstack-ceilometer | 07:04 | |
| *** eoutin has quit IRC | 07:04 | |
| *** eoutin has joined #openstack-ceilometer | 07:07 | |
| *** matsuhashi has quit IRC | 07:08 | |
| *** matsuhashi has joined #openstack-ceilometer | 07:11 | |
| *** matsuhashi has quit IRC | 07:17 | |
| *** ekarlso has joined #openstack-ceilometer | 07:17 | |
| *** matsuhashi has joined #openstack-ceilometer | 07:17 | |
| *** _nadya_ has quit IRC | 07:18 | |
| *** _nadya_ has joined #openstack-ceilometer | 07:21 | |
| *** Daviey has joined #openstack-ceilometer | 07:22 | |
| *** _nadya_ has quit IRC | 07:24 | |
| *** nati_ueno has quit IRC | 07:29 | |
| *** _nadya_ has joined #openstack-ceilometer | 07:30 | |
| *** fnaval has quit IRC | 07:32 | |
| *** nacim has joined #openstack-ceilometer | 07:37 | |
| *** zigo_ is now known as zigo | 07:55 | |
| *** idegtiarov has joined #openstack-ceilometer | 07:58 | |
| *** ildikov_ has joined #openstack-ceilometer | 08:04 | |
| *** ildikov has quit IRC | 08:04 | |
| *** eglynn has joined #openstack-ceilometer | 08:35 | |
| *** eglynn has quit IRC | 08:48 | |
| *** eglynn has joined #openstack-ceilometer | 08:50 | |
| openstackgerrit | ZhiQiang Fan proposed a change to openstack/python-ceilometerclient: Avoid empty alarm id when call alarm-update https://review.openstack.org/91301 | 08:59 |
| openstackgerrit | liusheng proposed a change to openstack/ceilometer: Improve the query_to_kwargs method https://review.openstack.org/90636 | 09:27 |
| DinaBelova | eglynn, o/ | 09:42 |
| eglynn | DinaBelova: yo | 09:42 |
| DinaBelova | I wanted to point your attention to one of the changes proposed now to the Ceilometer https://review.openstack.org/#/c/89756/ | 09:43 |
| DinaBelova | Liu Sheng has fixed lots of moments for now.. | 09:43 |
| openstackgerrit | liusheng proposed a change to openstack/ceilometer: Improve the query_to_kwargs method https://review.openstack.org/90636 | 09:43 |
| DinaBelova | but the thing is with the not approved BP | 09:43 |
| DinaBelova | so he can't move further I guess | 09:44 |
| eglynn | DinaBelova: I saw that patch, but held off commenting because there's a summit session scheduled to discuss this and other changes | 09:44 |
| DinaBelova | heh, ok, good to know! | 09:44 |
| eglynn | DinaBelova: http://summit.openstack.org/cfp/details/416 | 09:44 |
| DinaBelova | ok, thanks! | 09:45 |
| eglynn | DinaBelova: ... I'll comment on gerrit also | 09:45 |
| DinaBelova | eglynn, I just was lost there :) | 09:45 |
| DinaBelova | thanks for the direction) | 09:45 |
| eglynn | np! | 09:45 |
| *** denis_makogon has joined #openstack-ceilometer | 09:50 | |
| openstackgerrit | Sylvain Afchain proposed a change to openstack/ceilometer: Opencontrail network statistics driver https://review.openstack.org/85994 | 10:01 |
| *** alexpilotti has joined #openstack-ceilometer | 10:11 | |
| DinaBelova | eglynn, about your comments to the https://review.openstack.org/#/c/91046/1 - 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 |
| DinaBelova | and it won't work great with the tuple | 10:19 |
| DinaBelova | don't you think so? | 10:19 |
| *** nosnos has quit IRC | 10:21 | |
| DinaBelova | eglynn, so that will need additional checks in the code later in the method request workflow | 10:22 |
| eglynn | DinaBelova: yeah I guess append not working great with tuple was the point | 10:22 |
| eglynn | DinaBelova: 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 tuple | 10:22 |
| DinaBelova | yes... | 10:22 |
| DinaBelova | so possibly these several lines are ok, but keep code without the possible bugs | 10:22 |
| eglynn | DinaBelova: .. a-ha, I think I see ... you're concerned about the case where unit test does currently exercise the default case? | 10:22 |
| eglynn | DinaBelova: s/does/doesn't/ | 10:23 |
| DinaBelova | yes, and these too | 10:23 |
| eglynn | DinaBelova: ... k, stick that thought in gerrit for posterity and I'll reply there | 10:23 |
| DinaBelova | ok | 10:23 |
| DinaBelova | eglynn, replied) | 10:27 |
| *** nosnos has joined #openstack-ceilometer | 10:29 | |
| *** admin0 has joined #openstack-ceilometer | 10:37 | |
| *** openstackgerrit has quit IRC | 10:51 | |
| shardy | eglynn: hey, fyi added a response to your comment on https://review.openstack.org/#/c/87111/ | 10:53 |
| eglynn | shardy: ... thanks looking now | 10:53 |
| shardy | eglynn: IMO it would be a better pattern if ceilometer created the trust when the alarm is created, be interested to hear your thoughts | 10:53 |
| eglynn | shardy: ... /me is confused about how ceilometer could create the trust | 10:55 |
| eglynn | shardy: ... I thought the delegation flow was *from* heat *to* ceilo | 10:55 |
| eglynn | shardy: ... i.e. not ivce versa | 10:55 |
| eglynn | *vice | 10:55 |
| shardy | eglynn: no, ceilometer needs to impersonate the stack owning user, whose token is used when we create the alarm | 10:55 |
| shardy | so ceilometer has all the information required to create the trust between the ceilometer service user and the stack owner, during the creation of the alrm | 10:56 |
| shardy | alarm even | 10:56 |
| shardy | that is the same pattern we use creating a trust for autoscaling actions now in heat | 10:56 |
| eglynn | shardy: ... a-ha of course, I see, so only a valid token is required to create the trust | 10:56 |
| shardy | eglynn: yes | 10:56 |
| eglynn | shardy: ... yeah in that case I think it does make a lot more sense for ceilo to handle that | 10:57 |
| shardy | if 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 ceilometer | 10:57 |
| shardy | or rather the alarm action would appear to be from the stack owner | 10:57 |
| eglynn | shardy: ... yeap, and totally avoids the leakage of ceilo user identity into heat config, right? | 10:58 |
| shardy | it is more work on the ceilometer side, but it seems atm to make more sense | 10:58 |
| eglynn | shardy: ... so win, win | 10:58 |
| shardy | exactly, cos you already know what your service user details are | 10:58 |
| eglynn | shardy: yeap, agreed ... so that heat patch is -2'd pending the corresponding ceilo change, or? | 10:58 |
| eglynn | therve: ^^^ relevant chatter :) | 10:59 |
| shardy | it 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 |
| shardy | eglynn: I've just -1'd it pending discussion with therve | 10:59 |
| shardy | and yourself obviously ;) | 10:59 |
| eglynn | shardy: yeah, I guess it's kinda implicit that once you release a token into the wild, the receiver can do what it likes with it | 11:00 |
| shardy | I'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 |
| shardy | then that is used for subsequent alarm action notifications | 11:00 |
| eglynn | shardy: ... doesn't therve's initial version embed 'trust+' in the alarm action URL scheme? | 11:01 |
| shardy | it'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 anymore | 11:02 |
| eglynn | shardy: ... 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 |
| eglynn | shardy: ... also do we require one trust per alarm action, or one per alarm, or just one per alarm-owner? | 11:03 |
| shardy | eglynn: yeah, maybe that's enough, I guess we pass trust:<URL> and ceilometer has to add the trust-id@ bit | 11:03 |
| eglynn | shardy: yeah, that would probably suffice | 11:04 |
| shardy | eglynn: the trust is between the alarm owner and the ceilometer service user, so in theory only the latter | 11:04 |
| shardy | I guess it may be easier to just create one per alarm though and store it when the alarm is created | 11:05 |
| eglynn | shardy: k, so a little bit of extra logic might be required to tear down the trust when the last alarm for that user is deleted | 11:05 |
| shardy | One 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 default | 11:06 |
| eglynn | shardy: does that distinguished role have to be identified when the trust is created? | 11:07 |
| shardy | ceilometer 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 |
| shardy | eglynn: yes | 11:07 |
| shardy | it's a list of roles, which must be at least one, and the roles must be assigned to the user delegating them | 11:08 |
| eglynn | shardy: ... k, so in a sense we're getting identity leakage in the opposite direction (heat -> ceilo) | 11:08 |
| eglynn | shardy: ... unless this list of roles is embedded in the alarm action URL somehow? | 11:08 |
| shardy | well it's really dependent on the deployers rbac policies, we just added that role e.g to devstack to make things work | 11:09 |
| shardy | maybe we need a globall role like trust_ok or something | 11:10 |
| shardy | so users get explicitly added to some role which means delegation is allowed for them | 11:10 |
| shardy | or there could be a new ceilometer specific role, ceilometer_alarm_owner or something, but that starts getting cumbersome for users/deployers | 11:11 |
| eglynn | shardy: ... hmmm wouldn't using a single global role (trust_ok) be kinda removing one degree of freedom from the whole trusts mechanism? | 11:11 |
| eglynn | shardy: ... and hardcoding ceilo to always use ceilometer_alarm_owner role for the trust would seem overly restrictive too | 11:12 |
| shardy | eglynn: 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 separation | 11:13 |
| shardy | eglynn: the thing is, the role to be delegated is really a deployer decision, because they have visibility of the policies, and the user doesn't | 11:13 |
| shardy | so requiring them to provide a role when creating the alarm probably doesn't make sense | 11:14 |
| eglynn | shardy: ... 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 |
| shardy | eglynn: no, only the stack owner needs to have the role | 11:14 |
| shardy | then the role is delegated via the trust to the ceilometer service user (who does not need to have the role) | 11:15 |
| shardy | but whatever role is used must exist, and be assigned to the user creating the stack | 11:15 |
| eglynn | shardy: ... a-ha ok, got it backwards there for a second | 11:15 |
| shardy | so it does impact deployment mechanisms to an extent | 11:15 |
| shardy | (hence me bouncing ideas around which avoid a default proliferation of new roles) | 11:16 |
| eglynn | shardy: ... 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 |
| shardy | eglynn: 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 stack | 11:18 |
| shardy | https://github.com/openstack/heat/blob/master/etc/heat/policy.json | 11:19 |
| shardy | e.g we use another role "heat_stack_user" which is assigned to all in-instance users, so we limit the API surface they can access | 11:19 |
| *** denis_makogon has left #openstack-ceilometer | 11:19 | |
| eglynn | shardy: ... 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 |
| eglynn | shardy: ... so I was kinda expecting the delegated role to be really minimal | 11:22 |
| shardy | heat_stack_owner is the role delegated to the heat service user for doing autoscaling actions via a trust | 11:22 |
| shardy | heat_stack_user is an "untrusted" role we assign to users created by heat which are associated with in-instance credentials | 11:23 |
| shardy | e.g wait conditions | 11:23 |
| shardy | so the delegated role is really minimal by default | 11:23 |
| shardy | but for "real" deployments, it might be a list of roles required to access certain services, e.g nova | 11:24 |
| eglynn | shardy: ... k, so delegation of the heat_stack_owner role makes the ceilo alarm notifier capable of calling back on the autoscaling trigger endpoints | 11:24 |
| eglynn | ... but nothing more "destructive" than that? | 11:24 |
| shardy | eglynn: yeah that's basically the idea | 11:25 |
| shardy | with config file options such that deployers can customize what the delegated token can do depending on their environment | 11:25 |
| eglynn | shardy: cool, I was confused by the lack of reference to heat_stack_owner in the out-of-the-box policy.json | 11:26 |
| shardy | E.g by default, ceilometer probably only needs to be able to do this one action: | 11:26 |
| shardy | https://github.com/openstack/heat/blob/master/etc/heat/policy.json#L37 | 11:26 |
| shardy | eglynn: Yeah heat_stack_owner is really a dummy role, and alias for "whatever roles needed to launch stuff for autoscaling" | 11:26 |
| shardy | because the trust is used inside heat to make API calls, primarily to other services, not heat | 11:27 |
| eglynn | shardy: ... 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 |
| shardy | eglynn: that is a good question actually :) | 11:29 |
| shardy | eglynn: 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 stack | 11:29 |
| shardy | (assuming the new for icehouse instance-users stuff is being used) | 11:30 |
| shardy | so that pre-signed URL can only ever access that one stack | 11:30 |
| shardy | and the roles associated with it mean it has heat_stack_user, so the API surface is already limited as mentioned above | 11:31 |
| eglynn | shardy: cool, but the trust mechanism replaces the old pre-signed URL approach, or? | 11:31 |
| shardy | if 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 role | 11:31 |
| shardy | but not any separation between stacks | 11:31 |
| shardy | that is probably OK, as the ceilometer user is "trusted", unlike the agents in the instances | 11:32 |
| shardy | and 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 wish | 11:32 |
| eglynn | shardy: a-ha, k, so the lifecycle of the trust is really bound to the project ... as opposed, as opposed to the individual user or alarm | 11:32 |
| shardy | Yeah that's one of the reasons we moved to the more granular stack-domain-user model for in-instance credentials | 11:33 |
| shardy | probably removing the risk of replay attacks is more important than the ceilometer service sending an alarm to the wrong stack | 11:34 |
| shardy | If 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 owner | 11:35 |
| shardy | then heat "sees" ceilometer as another in-instance agent via the API | 11:35 |
| eglynn | shardy: cool, the veil is being lifted from mine eyes ... again ;) | 11:37 |
| eglynn | shardy: so to sum up ... what really makes the basic mechanism work is your earlier statement | 11: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* userB | 11:38 |
| eglynn | ... as long as userA has been passed a token by userB | 11:38 |
| shardy | eglynn: exactly | 11:38 |
| eglynn | ... /me was more thinking of the act of trust creation being the point at which privilege was *delegated* from userB to userA | 11:39 |
| eglynn | (as opposed to being grabbed by userA from userB) | 11:39 |
| therve | shardy, Catching up | 11:40 |
| eglynn | shardy: cool, that discussion clarified loads for me, thanks! | 11:40 |
| shardy | eglynn: 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 roles | 11:40 |
| shardy | it's just that in this case, the service (heat or ceilometer) is creating that trust for them | 11:40 |
| shardy | (using their token, passed to the service) | 11:41 |
| eglynn | yeah, 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 endpoint | 11:44 |
| eglynn | "/me was more thinking..." == "/me was previously incorrectly thinking..." | 11:44 |
| shardy | eglynn: not quite, the keystone API call would be made by userB (or rather by the ceilometer service using their token) | 11:45 |
| shardy | I'm talking about keystone identities not which entity makes the API request | 11:45 |
| therve | shardy, So, if ceilo creates the trust, it needs to know about the roles somehow, right? | 11:47 |
| eglynn | shardy: 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 |
| shardy | therve: yeah, or there needs to be a new ceilometer_alarm_owner role or something | 11:47 |
| *** admin0 has quit IRC | 11:48 | |
| eglynn | therve: ... or if that role needs to be controllable from the heat side, an alternative would be to embed it in the alarm action URl somehow | 11:48 |
| shardy | therve: 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 stack | 11:48 |
| shardy | the problem with that is the alarm is created by the stack-owner, not the stack-domain-user associated with e.g the ScalingPolicy | 11:49 |
| shardy | eglynn: yeah, that may end up being the most flexible approach | 11:49 |
| therve | shardy, Well, we should trust ceilometer, no? | 11:49 |
| shardy | therve: 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 attacks | 11:51 |
| therve | Hum okay. | 11:52 |
| therve | shardy, Sorry, but doesn't that contradict " if there's a way for us to reuse a stack-domain-user" ? | 11:52 |
| shardy | therve: 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 alarm | 11:53 |
| shardy | whereas with the trusts scheme it could | 11:53 |
| therve | Ah I see | 11:53 |
| shardy | minor issue, I should probably stop thinking out loud :) | 11:54 |
| *** fnaval has joined #openstack-ceilometer | 11:54 | |
| therve | shardy, So you're saying using trust is better, but trust scoped to a project would be better | 11:54 |
| shardy | therve: the trust is already scoped to a project, but it could be used to send alarms to any stack in the project | 11:54 |
| therve | Scoped to a stack | 11:54 |
| eglynn | yeap that's what I was getting at earlier with the stack segregation question, scoped to a single stack would be better surely? | 11:54 |
| eglynn | snap! | 11:54 |
| shardy | yup | 11:54 |
| shardy | if possible, it would be super-great if we could make it scoped to the stack, and driven by trusts | 11:55 |
| eglynn | yeah | 11:55 |
| therve | We would need to pass the credentials of the domain user to ceilo | 11:55 |
| therve | I think? | 11:56 |
| therve | No we would impersonate him | 11:56 |
| shardy | yeah, or go back to the current solution and create the trust and pass it to ceilometer | 11:56 |
| eglynn | so 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 token | 11: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 trusts | 11:57 |
| shardy | eglynn: yes, or leak the AS trigger URL, the trust ID, and the ceilometer service user credentials ;) | 11:57 |
| shardy | If that happens then I think all bets are off ;) | 11:57 |
| eglynn | yeah | 11:57 |
| therve | shardy, If we just change heat patch to create the trust for the stack domain user, that would work, no? | 11:58 |
| therve | Without changing anything in the trust notifier in ceilo | 11:58 |
| shardy | therve: yup, but the conversation started out with shouldn't ceilometer be creating the trust not heat | 11:58 |
| eglynn | ... and just to confirm, there's no stack segregation going on *regardless* of whomever (heat or ceilo) creates the trust? | 11:59 |
| therve | shardy, So what's the benefit of that? | 11:59 |
| eglynn | therve: no need for heat to know the ceilo user ID | 11:59 |
| therve | That's a small deployment issue, but okay | 11:59 |
| eglynn | (as per the comments on https://review.openstack.org/#/c/87111/2/etc/heat/heat.conf.sample ) | 12:00 |
| therve | shardy, So the problem is that we would need to create the alarm as the domain user? | 12:00 |
| therve | That would break assumptions of regular templates logic | 12:00 |
| shardy | therve: it seems like maybe the opportunity for additional separation may trump the slightly cleaner deployment pattern of ceilometer creating the trust | 12:00 |
| therve | :) | 12:01 |
| shardy | therve: yeah you're right, but we could create the trust between the stack-domain-user and the ceilometer user, and pass the trust | 12:01 |
| shardy | so to wrap up this long conversation, I am wrong ;) | 12:02 |
| *** matsuhashi has quit IRC | 12:02 | |
| *** admin0 has joined #openstack-ceilometer | 12:02 | |
| therve | Well not really :). But I think we can fix everything in Heat | 12:02 |
| *** matsuhashi has joined #openstack-ceilometer | 12:02 | |
| shardy | therve: yeah, it's been good to have this discussion anyway to bounce the various ideas around | 12:02 |
| shardy | eglynn: thanks for taking the time to go through this | 12:03 |
| *** matsuhashi has quit IRC | 12:03 | |
| eglynn | shardy: ... well thank you for being gentle in your explanations, all much clearer to me now! | 12:03 |
| shardy | eglynn: ha, cool, hopefully between us we now know how it should work :) | 12:04 |
| eglynn | yeap | 12:04 |
| *** liusheng has quit IRC | 12:06 | |
| *** eglynn-lunch has joined #openstack-ceilometer | 12:07 | |
| *** eglynn has quit IRC | 12:07 | |
| *** nosnos has quit IRC | 12:09 | |
| *** _nadya_ has quit IRC | 12:13 | |
| *** _nadya_ has joined #openstack-ceilometer | 12:14 | |
| *** jdob has joined #openstack-ceilometer | 12:17 | |
| *** eoutin has quit IRC | 12:17 | |
| *** erecio has joined #openstack-ceilometer | 12:20 | |
| *** eoutin has joined #openstack-ceilometer | 12:21 | |
| *** reazem has quit IRC | 12:27 | |
| *** reazem has joined #openstack-ceilometer | 12:28 | |
| *** erecio_1 has joined #openstack-ceilometer | 12:36 | |
| *** erecio has quit IRC | 12:38 | |
| *** ityaptin has quit IRC | 12:44 | |
| *** julim has joined #openstack-ceilometer | 12:49 | |
| *** ityaptin has joined #openstack-ceilometer | 12:54 | |
| *** eglynn has joined #openstack-ceilometer | 12:58 | |
| *** inc0 has joined #openstack-ceilometer | 13:01 | |
| *** bada has quit IRC | 13:05 | |
| *** eoutin has quit IRC | 13:06 | |
| *** rdmcnair has joined #openstack-ceilometer | 13:09 | |
| *** eglynn has quit IRC | 13:11 | |
| *** reazem has quit IRC | 13:15 | |
| *** joesavak has joined #openstack-ceilometer | 13:16 | |
| *** reazem has joined #openstack-ceilometer | 13:18 | |
| *** thomasem has joined #openstack-ceilometer | 13:19 | |
| *** _nadya_ has quit IRC | 13:28 | |
| *** rdmcnair has quit IRC | 13:29 | |
| *** eoutin has joined #openstack-ceilometer | 13:29 | |
| *** mengxd has joined #openstack-ceilometer | 13:29 | |
| *** fnaval has quit IRC | 13:30 | |
| *** inc0 has quit IRC | 13:31 | |
| *** eoutin has quit IRC | 13:33 | |
| *** erecio_1 has quit IRC | 13:39 | |
| *** mengxd has quit IRC | 13:42 | |
| *** eglynn has joined #openstack-ceilometer | 13:44 | |
| *** gordc has joined #openstack-ceilometer | 13:44 | |
| *** jmckind has joined #openstack-ceilometer | 13:50 | |
| *** _nadya_ has joined #openstack-ceilometer | 13:52 | |
| *** eglynn-lunch has quit IRC | 13:53 | |
| *** sdake_ has quit IRC | 13:53 | |
| *** openstackgerrit has joined #openstack-ceilometer | 13:55 | |
| *** erecio_1 has joined #openstack-ceilometer | 13:57 | |
| *** nealph has quit IRC | 13:58 | |
| *** fnaval has joined #openstack-ceilometer | 13:59 | |
| *** prad_ has joined #openstack-ceilometer | 14:05 | |
| ityaptin | eglynn: Hi! Sorry for the late answer. | 14:08 |
| ityaptin | eglynn: 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 |
| eglynn | ityaptin: np! | 14:08 |
| ityaptin | eglynn: 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 |
| eglynn | ityaptin: so the sample timestamp and recorded_at values stored in the DB are insufficient | 14:10 |
| eglynn | ityaptin: ... because you want to separate out the AMQP lag for the metering message and the storage latency within the collector, correct? | 14:10 |
| ityaptin | yes) | 14:11 |
| eglynn | ityaptin: cool, and yeah the variance in the user_id and project_id is not a big deal | 14:12 |
| ityaptin | yes) | 14:13 |
| eglynn | ityaptin: ... /me was thinking though that a more realistic traffic mix | 14:13 |
| eglynn | ityaptin: ... (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 deployments | 14:14 |
| eglynn | ityaptin: ... but probably wouldn't alter the results a great deal | 14:14 |
| ityaptin | eglynn: I think, for performance of collector it has not any differences. | 14:16 |
| eglynn | ityaptin: ... yeap, very marginal at most | 14:17 |
| eglynn | jd__, 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 |
| eglynn | http://junodesignsummit.sched.org/overview/type/ceilometer | 14:23 |
| jd__ | nop | 14:24 |
| jd__ | that sounds like a good procrastination before the week end, thanks eglynn | 14:24 |
| jd__ | I'm going to make my summit schedule right now | 14:24 |
| eglynn | jd__: LOL ... displacement activity is my speciality ;) | 14:24 |
| jd__ | :D | 14:24 |
| gordc | 9am is nap time for me. i'm skipping your session jd__ | 14:26 |
| gordc | luckily my hotel this time isn't a 1hr train ride like hong kong so early sessions are a bit better. | 14:27 |
| jd__ | hehe | 14:28 |
| jd__ | eglynn: ok looks like you avoided to conflict with the import sessions that are breaks and lunches, so that LGTM :D | 14:29 |
| *** raymondr has joined #openstack-ceilometer | 14:29 | |
| eglynn | jd__: ... yeap I avoided that banana skin just about | 14:30 |
| *** nati_ueno has joined #openstack-ceilometer | 14:31 | |
| ildikov_ | gordc: I know that one hour feeling very well... :S :) | 14:34 |
| ildikov_ | eglynn: fine with me | 14:34 |
| *** erecio_1 has quit IRC | 14:37 | |
| *** ildikov_ has quit IRC | 14:44 | |
| *** ildikov_ has joined #openstack-ceilometer | 14:44 | |
| *** prad_ has left #openstack-ceilometer | 14:52 | |
| *** prad_ has joined #openstack-ceilometer | 14:53 | |
| *** _nadya_ has quit IRC | 14:54 | |
| *** fabio has joined #openstack-ceilometer | 15:07 | |
| *** eglynn is now known as eglynn-afk | 15:09 | |
| *** ildikov_ has quit IRC | 15:13 | |
| *** fnaval has quit IRC | 15:22 | |
| *** erecio_1 has joined #openstack-ceilometer | 15:22 | |
| *** fnaval has joined #openstack-ceilometer | 15:22 | |
| *** fnaval has quit IRC | 15:27 | |
| *** fnaval has joined #openstack-ceilometer | 15:29 | |
| *** sdake_ has joined #openstack-ceilometer | 15:32 | |
| *** sdake_ has joined #openstack-ceilometer | 15:32 | |
| *** _nadya_ has joined #openstack-ceilometer | 15:32 | |
| *** fabio has quit IRC | 15:32 | |
| *** _cjones_ has joined #openstack-ceilometer | 15:37 | |
| *** _cjones_ has quit IRC | 15:42 | |
| *** _cjones_ has joined #openstack-ceilometer | 15:43 | |
| *** rdmcnair has joined #openstack-ceilometer | 15:43 | |
| *** admin0 has quit IRC | 15:43 | |
| *** eglynn-afk has quit IRC | 15:45 | |
| *** vrovachev has quit IRC | 15:45 | |
| *** admin0 has joined #openstack-ceilometer | 15:46 | |
| *** erecio_1 has quit IRC | 15:46 | |
| openstackgerrit | Ionut Artarisi proposed a change to openstack/ceilometer: reconnect to mongodb on connection failure https://review.openstack.org/86609 | 15:49 |
| *** admin0 has left #openstack-ceilometer | 15:55 | |
| *** erecio_1 has joined #openstack-ceilometer | 15:59 | |
| *** jsavak has joined #openstack-ceilometer | 16:00 | |
| *** Ruetobas has quit IRC | 16:01 | |
| *** packet has joined #openstack-ceilometer | 16:01 | |
| *** joesavak has quit IRC | 16:02 | |
| *** gordc has quit IRC | 16:02 | |
| *** gordc1 has joined #openstack-ceilometer | 16:02 | |
| *** packet has quit IRC | 16:03 | |
| *** Ruetobas has joined #openstack-ceilometer | 16:03 | |
| *** sdake_ has quit IRC | 16:03 | |
| *** packet has joined #openstack-ceilometer | 16:05 | |
| *** nacim has quit IRC | 16:05 | |
| *** packet has quit IRC | 16:05 | |
| *** packet has joined #openstack-ceilometer | 16:06 | |
| *** sdake_ has joined #openstack-ceilometer | 16:07 | |
| *** Ruetobas has quit IRC | 16:07 | |
| openstackgerrit | Igor Degtiarov proposed a change to openstack/ceilometer: Implement record_events method for HBase https://review.openstack.org/91408 | 16:11 |
| *** _cjones_ has quit IRC | 16:12 | |
| *** _cjones_ has joined #openstack-ceilometer | 16:13 | |
| *** Ruetobas has joined #openstack-ceilometer | 16:13 | |
| *** idegtiarov has quit IRC | 16:14 | |
| *** eglynn has joined #openstack-ceilometer | 16:16 | |
| *** nati_ueno has quit IRC | 16:16 | |
| *** _cjones_ has quit IRC | 16:17 | |
| *** sdake_ has quit IRC | 16:29 | |
| *** erecio_1 has quit IRC | 16:31 | |
| *** joesavak has joined #openstack-ceilometer | 16:43 | |
| *** jsavak has quit IRC | 16:46 | |
| *** jmckind has quit IRC | 16:51 | |
| *** erecio_1 has joined #openstack-ceilometer | 16:55 | |
| *** gordc has joined #openstack-ceilometer | 17:00 | |
| *** nati_ueno has joined #openstack-ceilometer | 17:00 | |
| *** nati_ueno has quit IRC | 17:01 | |
| nsaje | eglynn: no problem for me! | 17:01 |
| *** gordc1 has quit IRC | 17:01 | |
| *** _nadya_ has quit IRC | 17:02 | |
| *** nati_ueno has joined #openstack-ceilometer | 17:03 | |
| *** bada has joined #openstack-ceilometer | 17:13 | |
| *** bada has quit IRC | 17:14 | |
| *** Ju has joined #openstack-ceilometer | 17:14 | |
| *** Alexei_987 has joined #openstack-ceilometer | 17:18 | |
| *** Ju has quit IRC | 17:19 | |
| *** Ju has joined #openstack-ceilometer | 17:21 | |
| eglynn | nsaje: cool :) | 17:25 |
| *** nati_ueno has quit IRC | 17:30 | |
| *** nati_ueno has joined #openstack-ceilometer | 17:30 | |
| *** nati_ueno has quit IRC | 17:31 | |
| *** nati_ueno has joined #openstack-ceilometer | 17:31 | |
| *** _cjones_ has joined #openstack-ceilometer | 17:43 | |
| *** erecio_1 has quit IRC | 17:45 | |
| *** jmckind has joined #openstack-ceilometer | 17:50 | |
| *** jmckind has quit IRC | 17:56 | |
| *** jmckind has joined #openstack-ceilometer | 17:56 | |
| *** nati_ueno has quit IRC | 18:07 | |
| *** nati_ueno has joined #openstack-ceilometer | 18:07 | |
| *** ildikov has joined #openstack-ceilometer | 18:12 | |
| *** promulo has joined #openstack-ceilometer | 18:16 | |
| *** nati_ueno has quit IRC | 18:20 | |
| *** nati_ueno has joined #openstack-ceilometer | 18:21 | |
| *** erecio has joined #openstack-ceilometer | 18:27 | |
| *** promulo has quit IRC | 18:40 | |
| *** _nadya_ has joined #openstack-ceilometer | 18:45 | |
| *** eglynn has quit IRC | 18:46 | |
| *** nati_ueno has quit IRC | 18:47 | |
| *** nati_ueno has joined #openstack-ceilometer | 18:48 | |
| *** nati_ueno has quit IRC | 18:49 | |
| *** dperaza has quit IRC | 18:49 | |
| *** nati_ueno has joined #openstack-ceilometer | 18:51 | |
| *** dperaza has joined #openstack-ceilometer | 18:55 | |
| *** sdake_ has joined #openstack-ceilometer | 18:59 | |
| *** promulo has joined #openstack-ceilometer | 19:07 | |
| gordc | thomasem: ping | 19:09 |
| thomasem | gordc: pong | 19:09 |
| thomasem | What's the story? :) | 19:09 |
| gordc | hey Thomas, i was going to start looking at this: https://bugs.launchpad.net/ceilometer/+bug/1267865 | 19:09 |
| gordc | do you know an easy way to build a massive events db using devstack? | 19:10 |
| thomasem | gordc: https://github.com/rackerlabs/ceilometer-load-tests | 19:10 |
| thomasem | gordc: That's how I generated the crazy large events DB earlier | 19:11 |
| thomasem | When I found that bug | 19:11 |
| gordc | thomasem: cool ok. i'll take a look at that. | 19:11 |
| gordc | tahnks | 19:11 |
| gordc | thanks* | 19:11 |
| thomasem | That 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 |
| thomasem | Another way would be to script a bunch of create/delete commands on DevStack | 19:12 |
| gordc | thomasem: exactly what i want. i'll give the repo a try to see if still works. | 19:12 |
| thomasem | Awesome, sounds great! :) | 19:13 |
| *** nati_ueno has quit IRC | 19:25 | |
| *** eglynn has joined #openstack-ceilometer | 19:40 | |
| *** _nadya_ has quit IRC | 19:53 | |
| *** nati_ueno has joined #openstack-ceilometer | 20:00 | |
| *** nati_ueno has quit IRC | 20: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-ceilometer | 20:24 | |
| *** nati_ueno has joined #openstack-ceilometer | 20:25 | |
| *** sdake_ has quit IRC | 20:39 | |
| *** shakayumi has joined #openstack-ceilometer | 20:47 | |
| *** shakayumi has quit IRC | 20:47 | |
| *** erecio has quit IRC | 20:58 | |
| *** jdob has quit IRC | 20:59 | |
| *** _nadya_ has quit IRC | 21:03 | |
| *** sdake_ has joined #openstack-ceilometer | 21:03 | |
| *** thomasem has quit IRC | 21:04 | |
| *** thomasem has joined #openstack-ceilometer | 21:05 | |
| *** thomasem has quit IRC | 21:10 | |
| *** shakayumi has joined #openstack-ceilometer | 21:15 | |
| *** shakayumi has quit IRC | 21:15 | |
| *** reazem has quit IRC | 21:33 | |
| *** jmckind has quit IRC | 21:44 | |
| *** promulo has quit IRC | 21:46 | |
| *** eglynn has quit IRC | 21:54 | |
| *** raymondr has quit IRC | 21:56 | |
| *** gordc has quit IRC | 21:57 | |
| *** shardy is now known as shardy_afk | 22:01 | |
| *** nati_ueno has quit IRC | 22:15 | |
| *** nati_ueno has joined #openstack-ceilometer | 22:28 | |
| *** fnaval has quit IRC | 22:34 | |
| *** fnaval has joined #openstack-ceilometer | 22:36 | |
| *** prad_ has quit IRC | 22:37 | |
| *** nati_ueno has quit IRC | 22:43 | |
| *** nati_ueno has joined #openstack-ceilometer | 22:45 | |
| *** fnaval has quit IRC | 22:47 | |
| *** rdmcnair has quit IRC | 22:49 | |
| *** joesavak has quit IRC | 23:40 | |
| *** nati_ueno has quit IRC | 23:48 | |
| *** nati_ueno has joined #openstack-ceilometer | 23:48 | |
| *** nati_ueno has quit IRC | 23:54 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!