21:00:22 <jd__> #startmeeting ceilometer
21:00:23 <openstack> Meeting started Wed Jun 19 21:00:22 2013 UTC.  The chair is jd__. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:26 <openstack> The meeting name has been set to 'ceilometer'
21:00:34 <asalkeld> o/
21:00:36 <sandywalsh> o/
21:00:40 <eglynn-afk> o/
21:00:40 <nealph> \o
21:00:43 <DanD> o/
21:01:12 <jd__> #link https://wiki.openstack.org/wiki/Meetings/MeteringAgenda
21:01:31 <jd__> I'll start with my havana-2 review if you don't mind eglynn
21:01:43 <eglynn> jd__:  shoot
21:01:48 <jd__> #topic Review Havana-2 milestone
21:01:50 <dhellmann> o/
21:01:50 <jd__> #link https://launchpad.net/ceilometer/+milestone/havana-2
21:02:11 <jd__> so ttx thinks we're on track and starts asking question about the High bp here
21:02:36 <jd__> eglynn: typically you seems to have a lot and only one started, will everything be ok?
21:02:41 <jd__> -s
21:03:00 <eglynn> yep, I might bump a couple of minor ones
21:03:06 <jd__> havana-2 is in 1 month from now
21:03:10 <eglynn> e.g. https://blueprints.launchpad.net/ceilometer/+spec/transformer-unit
21:03:17 * dhellmann will be starting his high bp late this week or early next week
21:03:29 <eglynn> i.e. bump that transformer one to h3
21:03:33 <jd__> eglynn: ok, if you need some help about this one I can probably take it over or assign someone
21:03:41 <eglynn> k, cool
21:04:05 <jd__> dhellmann: cool
21:04:17 <jd__> otherwise we're pretty ok!
21:04:33 <jd__> and if you've some time, code reviews would be nice too :)
21:05:28 <asalkeld> yea, my reviews have been patchy - been working on heat
21:05:34 <jd__> ok, moving on :)
21:05:39 <jd__> asalkeld: I guessed so :)
21:05:50 <jd__> #topic eglynn: Discuss preferred approach to detailed metering (CPU, network I/O, disk etc.) of nodes managed by the baremetal virt driver
21:06:00 <eglynn> ok, so the basic requirement is captured here ...
21:06:06 <eglynn> #link https://bugs.launchpad.net/nova/+bug/1188218
21:06:08 <uvirtbot> Launchpad bug 1188218 in tripleo "Support standard ceilometer compute metrics with nova baremetal" [Medium,Triaged]
21:06:15 <jd__> is that related with the blueprint we have on hardware monitoring?
21:06:17 <eglynn> obviously in the baremetal case, no libvirt => current ceilo compute agent will not cut it for detailed metering
21:06:20 <jd__> or can that be related?
21:06:35 <asalkeld> eglynn, someone just pointed me at https://github.com/racker/virgo
21:06:36 <jd__> right, I already asked the question in the bug report.
21:07:14 <jd__> there's Lua in there
21:07:16 * jd__ runs
21:07:23 <asalkeld> yea, and c
21:07:34 <eglynn> jd__: related to https://blueprints.launchpad.net/openstack/?searchtext=monitoring-physical-devices do you mean?
21:07:39 <asalkeld> just saying...
21:07:40 <jd__> I don't run on C, it might bites otherwise
21:07:46 <jd__> eglynn: yeah
21:08:01 <eglynn> jd__: yep, that one possibility
21:08:07 <kgriffs> it might be interesting to do something in the spirit of virgo, but using Python
21:08:17 <eglynn> however I don't fully understand how that hardware agent works
21:08:37 <eglynn> i.e. would the agent run on the baremetal host?
21:08:45 <jd__> eglynn: I admit I stiil didn't take the time to review deeply
21:08:45 <eglynn> or externally?
21:08:56 <sandywalsh> asalkeld, could Diamond not do it?
21:09:13 <dhellmann> sandywalsh: you took the words right out of my keyboard
21:09:31 <asalkeld> sandywalsh, maybe
21:09:31 <sandywalsh> :)
21:09:43 <asalkeld> you mean running on the instances?
21:09:51 <asalkeld> auth would be an issue
21:10:15 <dhellmann> the agent could publish to the rest api, right?
21:10:18 <eglynn> yeah, so on the subject of auth
21:10:24 <jd__> dhellmann: I was about to say that
21:10:29 <sandywalsh> if it's running on the instances, that would be an issue for any solution
21:10:30 <eglynn> the agent would need to know os_username, os_passeord etc
21:10:44 <sandywalsh> (ie. if there's no host/hypervisor under the instance)
21:10:46 <asalkeld> eglynn, keypair
21:10:47 <jd__> just build an hardware agent that pushes metrics via the REST API and that's it
21:11:08 <jd__> basically the use case of such hardware monitoring is the same as monitoring something external to OS
21:11:09 <eglynn> but maybe that's no worse than the heat approach of pushing out the AWS access and secret key?
21:11:13 <eglynn> (IIUC)
21:11:26 <eglynn> https://github.com/stackforge/tripleo-image-elements/blob/master/elements/heat-cfntools/os-config-applier/etc/cfn/cfn-credentials
21:11:42 <asalkeld> yip that is it
21:12:02 <sandywalsh> eglynn, perhaps we could issue a revokable "API key" that the agent could use to push data, but the user could take away if needed or abused
21:12:04 <jd__> eglynn: these are users credentials, right?
21:12:11 <eglynn> so is that any more secure, really?
21:12:18 <sandywalsh> we'd still need proper rate limiting anyway
21:12:19 <asalkeld> https://github.com/openstack/heat-cfntools/blob/master/bin/cfn-push-stats
21:12:29 <dhellmann> sandywalsh: that sounds like a keystone token?
21:12:36 <asalkeld> we have this little script we use in heat ^
21:12:37 <eglynn> jd__: creds sufficient to POST stats to the ceilo API
21:12:53 <asalkeld> sandywalsh, +
21:12:55 <jd__> eglynn: fair enough
21:13:21 <sandywalsh> dhellmann, slightly different, kind of like when you let Twitter issue another api token
21:13:21 <jd__> eglynn: but how can ceilometer/keystone issue such special creds? we don't have delegatino or anything AFAIK
21:13:22 <dhellmann> asalkeld: if you have that, why are we building another? :-)
21:13:30 <eglynn> sandywalsh: well what would be nice would the AWS AMI style of key rotation
21:13:34 <dhellmann> sandywalsh: ok, I thought keystone could do something similar
21:13:53 <asalkeld> yea, we need to move that into ceilo domian
21:14:07 <sandywalsh> keystone can issue more tokens but they're still tied to that use (acting as that user), no on-behalf of, with limited access
21:14:19 <dhellmann> asalkeld: where do the values for the args come from?
21:14:19 <sandywalsh> for example, the token couldn't be used to stop the instance
21:14:27 <asalkeld> psutil
21:14:38 <asalkeld> dhellmann, o
21:14:43 <dhellmann> so there's a wrapper script that calls psutil and then invokes this script?
21:14:44 <asalkeld> dhellmann, the template
21:15:06 <asalkeld> no the template sets up the args
21:15:22 <asalkeld> I'll get a like
21:15:25 <asalkeld> link
21:15:29 <dhellmann> how does the template know, for example, the value for --mem-util?
21:15:53 <dolphm> reading back... user to user role delegation per project is available in grizzly via https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3-os-trust-ext.md
21:16:16 <asalkeld> dhellmann, https://github.com/openstack/heat-templates/blob/master/cfn/AutoScalingMultiAZSample.template#L224
21:16:23 <jd__> dolphm: ah interesting
21:16:24 <asalkeld> dhellmann, it's not a value
21:16:44 <asalkeld> just please send memutils
21:17:35 <dhellmann> ah, I see
21:17:38 <dhellmann> I thought psutil was a cli
21:18:01 <eglynn> dolphm: on the keyestone trusts: "The trust may only be valid for a specified time period, as defined by expires_at"
21:18:17 * eglynn wonders if if a trust can last forever effectively ...
21:18:28 <asalkeld> dhellmann, https://code.google.com/p/psutil/
21:18:36 <dhellmann> asalkeld:
21:18:40 <dolphm> eglynn: yes, just don't specify an expiration
21:18:47 <dhellmann> asalkeld: cool
21:18:49 <eglynn> k
21:18:54 <dolphm> that could be worded more clealry
21:19:14 <jd__> so we would have to use a special role or something IIUC?
21:19:16 <dolphm> Optionally, the trust may only be valid...
21:19:31 <eglynn> so I guess most basic question is whether we've confidence in the hardware-agent landing anytime soon
21:19:40 <eglynn> or whether it's better to concentrate on a simple on-host script and deal with the auth issue in some way
21:19:41 * dhellmann shrugs
21:19:51 <eglynn> e.g. via trusts as suggested above
21:19:53 <dhellmann> we have the trust issue either way, right?
21:20:09 <sandywalsh> https://github.com/BrightcoveOS/Diamond
21:20:10 <eglynn> yep, I guess
21:20:10 <dhellmann> we can't assume the ceilometer service is going to be able to talk to the instance
21:20:23 <jd__> eglynn: it can land if we review it
21:20:24 <dhellmann> the connection has to come out of the instance to a potentially public API
21:20:31 <jd__> dhellmann: +1
21:20:35 <sandywalsh> diamond also has hypervisor support so it can be used on both sides of the fence
21:20:55 <sandywalsh> and it already has graphite/statsd/etc support
21:21:17 <sandywalsh> (and we've already rolled it out internally ... :)
21:21:27 <eglynn> sandywalsh: "on both sides of the fence" == "inside or outside the baremetal host"?
21:21:35 <sandywalsh> eglynn, yep
21:21:44 <eglynn> k
21:21:50 <sandywalsh> eglynn, under a hypervisor or not
21:22:08 <asalkeld> sandywalsh, that's great but again we need to get it to talk to ceiloapi
21:22:22 <dhellmann> asalkeld: there's a "plugin" system for creating publishers, sort of like ours
21:22:29 <asalkeld> ok
21:22:35 <sandywalsh> same problem regardless of the solution you pick. diamond has a nice driver interface
21:22:40 <dhellmann> it would work ok for running on the host and collecting data, because we could configure tenant id and stuff
21:22:42 <asalkeld> well that is cool
21:22:58 <dhellmann> I'm not so sure about on the hypervisor side, since we couldn't tie usage for a given instance to a tenant from the outside as easily
21:23:07 <dhellmann> although it would work well for monitoring the hypervisor itself, for the scheduler
21:23:31 <asalkeld> in instance would be fine
21:23:35 <dhellmann> but one problem at a time -- let's see if it works for collecting data from inside the instance first
21:23:39 <asalkeld> we just need the publisher
21:23:49 <eglynn> so are we saying that all on-host approaches would suffer from the same auth issue? (i.e. needing to talk to the ceilo API)
21:23:54 <dhellmann> and we need some sort of deployment instructions
21:24:00 <dhellmann> eglynn: yes
21:24:06 <asalkeld> sandywalsh, thanks I didn't know about the publisher plugin
21:24:16 <sandywalsh> asalkeld, np
21:24:16 <dhellmann> you cannot assume that the instance can talk to protected services through back-channels
21:24:45 <dhellmann> I could see us, eventually, supporting several data collection tools inside the instance
21:24:52 <sandywalsh> right, we have the rackspace agent, which uses the xen back-channel, but it's still an optional component the user can opt-out of
21:24:56 <dhellmann> that way tenants can choose to run something they're comfortable with
21:25:16 <dhellmann> the heat script and a diamond plugin seem like good places to start
21:25:25 <asalkeld> yip
21:25:38 <dhellmann> I suggest we create separate git repos for each of these clients, so they can be packaged and distributed separately from the rest of ceilometer
21:25:40 <eglynn> yep the heat scrtip definitely has the benefit of simplicity
21:25:53 <sandywalsh> https://github.com/rackerlabs/openstack-guest-agents-unix
21:25:58 <dhellmann> some day someone will need to write a windows client, too, I suppose
21:26:07 <jd__> dhellmann: +1
21:26:11 <sandywalsh> we have a windows one too
21:26:20 <dhellmann> cool
21:26:34 <sandywalsh> https://github.com/rackerlabs/openstack-guest-agents-windows-xenserver
21:26:41 <dhellmann> so is the roadmap 1) heat script 2) diamond publisher 3) other ?
21:26:47 <sandywalsh> it would be nice to abstract the xen stuff and make it generic
21:26:49 <eglynn> dhellmann: yep, and then tie into tripleO via a ceilometer element
21:27:02 <eglynn> in the style of https://github.com/stackforge/tripleo-image-elements/tree/master/elements
21:27:11 <dhellmann> where other might be something based on all the fancy agents the rackers keep building :-)
21:28:02 * dhellmann needs to read more about triple0
21:28:07 <eglynn> given the buzz behind tripleO, use of the baremetal driver is going to be widespread
21:28:17 * eglynn state the obvious again ... ;)
21:28:44 <dhellmann> yeah, we're looking at it internally, too
21:29:10 <eglynn> so defo something we or the tripleO team will need to get to grips with
21:29:30 <eglynn> anyway some good ideas above
21:29:37 <eglynn> good food for thought ...
21:29:38 <sandywalsh> we can probably arrange a meetup at rackspace to go over TripleO if that's of interest?
21:30:22 <dhellmann> that might be cool, but it would have to wait. I'm seriously overbooked right now.
21:30:23 <eglynn> sandywalsh: interesting, we've got some Red Hatters ramping up on tripleO
21:30:51 <dhellmann> it would probably make as much sense for me to send one of our ops guys, so do let me know if you schedule something sandywalsh
21:31:07 <sandywalsh> k, I'll send it up the flagpole
21:31:10 <dhellmann> ty
21:31:31 <eglynn> yep similarly, keep us informed if it's a runner ...
21:32:05 <jd__> should we move on to the next topic?
21:32:26 <eglynn> next one should be quicker ;)
21:32:32 <jd__> #topic eglynn: discuss timing of next python-ceilometerclient release (one distro has started to carry additional patches as there's no stable branches for clients upstream)
21:32:49 <jd__> which distro is doing that?
21:32:52 <eglynn> k, so last ceiloclient release was 2013-03-28
21:33:00 <eglynn> jd__: RHOS
21:33:14 <dhellmann> is there any reason not to just release every month or so, if there are changes?
21:33:15 <eglynn> (just the change to make the v2 API the default ...)
21:33:18 <jd__> obviously! :p
21:33:26 <jd__> dhellmann: I can't see any
21:33:38 <jd__> eglynn: could/would you take care of it?
21:33:44 <eglynn> jd__: sure
21:33:49 <jd__> I mean at least this time
21:34:02 <eglynn> understood
21:34:07 <asalkeld> maybe have this as a running topic? "do we need  a client release"
21:34:11 <jd__> though I don't mind if you release once in a while
21:34:22 <jd__> we have no bp to implement in this, we have tests to know it works :)
21:34:24 <dhellmann> asalkeld: +1
21:34:40 <eglynn> asalkeld tell me it's just a case of pushing a tag, so it could be done very frequently if we're so inclined ...
21:34:44 <jd__> asalkeld: fair enough, I'll add in the agenda then
21:34:49 <eglynn> cool
21:34:58 <asalkeld> yea
21:35:01 <asalkeld> git tap
21:35:06 <asalkeld> git tag
21:35:17 <asalkeld> git push --tags
21:35:22 <dhellmann> I think it needs to be a signed tag, but otherwise it doesn't have to be special
21:35:23 <asalkeld> that's it
21:35:32 <asalkeld> yea, maybe
21:35:39 <asalkeld> git tag -s
21:35:43 <dhellmann> yeah
21:36:12 <eglynn> so the lack of stable branches in the python-*clients upstream behooves us to release often I think
21:36:58 <jd__> yep
21:36:59 <dhellmann> yep
21:37:03 <asalkeld> I need to go soon
21:37:09 * dhellmann there's an echo in here
21:37:18 <jd__> here here here he….
21:37:28 <asalkeld> (kids/school/breakfast/mayhem)
21:37:34 <jd__> I think we're good to got
21:37:36 <kgriffs> O/
21:37:37 <jd__> #topic open discussion
21:37:41 <jd__> anything to add?
21:37:43 <kgriffs> quick question
21:38:06 <kgriffs> thinking longer-term, will ceilometer ever be exposed to tenants as a sort of generic monitoring service?
21:38:46 <jd__> users have access to their meters
21:38:56 <jd__> they will have alarming soon
21:39:02 <kgriffs> oic
21:39:03 <jd__> does that quality as what you heard with monitoring, I don't know
21:39:08 <jd__> s/heard/mean/
21:39:36 <eglynn> s/quality/qualify/ ?
21:39:46 <kgriffs> would it be helpful for users to be able to set custom monitors, like write a script to check my special app or something?
21:40:16 <eglynn> currently the idea is threshold checking for ceilo meters only
21:40:28 <eglynn> (i.e. not for custom application states)
21:40:58 <kgriffs> ok. seems like there was a project someone talked about at the last summit that was trying to be more generic like that, and I was wondering how that meshed with ceilometer's roadmap
21:41:10 <nealph> kgriffs: is there a specific requirement in your use case that rules out using the reporting api?
21:42:25 <jd__> eglynn: s// indeed :)
21:42:28 <kgriffs> no, I was just wondering about custom collectors in the agent.
21:42:59 <kgriffs> thinking longer term, Rackspace has a cloud monitoring product and it would be nice to see that built on OpenStack projects some day
21:43:40 <dhellmann> kgriffs: ceilometer itself doesn't care what "meter" a sample is for
21:43:41 <eglynn> cloudkick?
21:43:48 <dhellmann> so it's just a question of how to get the data into the system
21:43:52 <kgriffs> right
21:44:16 <dhellmann> if you have access to the message bus, that's one way
21:44:19 <kgriffs> we currently use virgo which can pull down signed scripts and run them to do custom checks
21:44:46 <kgriffs> it would be cool if diamond could support that, but it may be out of scope for that project.
21:44:56 * kgriffs thinking out loud
21:45:06 <nealph> dhellmann: that's the yang to my reporting comment yin. :)
21:46:09 <dhellmann> yep
21:46:51 <sandywalsh> gotta jump off  ... later guys!
21:46:57 <jd__> cya
21:47:02 <eglynn> bye
21:47:06 <kgriffs> ok, cool. this all pie-in-the-sky, but good to keep on the radar
21:47:14 <jd__> closing the meeting, continue to hangout in #openstack-metering if you need
21:47:23 <kgriffs> kk
21:47:27 <jd__> have a nice day/night/whatever and thanks for coming :)
21:47:33 <jd__> #endmeeting