16:00:03 #startmeeting 16:00:03 #meetingtopic Ceilometer 16:00:03 #chair nijaba 16:00:03 #link http://wiki.openstack.org/Meetings/MeteringAgenda 16:00:04 Meeting started Thu Jun 21 16:00:03 2012 UTC. The chair is nijaba. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:08 Current chairs: nijaba 16:00:22 present 16:00:23 #info dachary will unfortunately not be able to join us this week for work related reasons, he asked me to present his excuses. 16:00:32 jd___: around? 16:00:37 anyone else? 16:00:49 i'm here 16:01:04 #topic actions from previous meetings 16:01:17 #topic nijaba: to point to the calculator in the blueprint 16:01:17 this is done. Available at 16:01:17 #link http://wiki.openstack.org/EfficientMetering#Volume_of_data 16:01:31 any comments on this? 16:01:42 nope 16:01:46 #topic dhellmann: start mapping API queries to database engine methods 16:02:01 we ran a few different numbers through the calculator. it's a good tool for estimating for us. 16:02:13 thanks dhellmann :) 16:02:21 I posted a proposed API to the list but haven't seen any feedback. Did anyone have a chance to review it? 16:02:58 dhellmann: I did, and I am quite happy with your proposal. I don;t have any clean solution for the problem you stated though 16:03:21 maybe when we start the implementation the solution will become more clear 16:03:33 * nijaba crosses his fingers 16:03:49 dhellmann: probably 16:04:11 ok, moving on then :) 16:04:14 #topic dhellmann: look at existing plugins and pick one of each for examples in docs and email info on examples to nijaba 16:04:15 I can confirm this was done and I received dhellmann's email 16:04:15 dhellmann: that seems at least as a good boilerplate 16:04:40 thanks for this dhellmann 16:05:00 thank you for volunteering to bootstrap the documentation :-) 16:05:16 dhellmann: why don't you want to make the two parameters optionals and add an assert at the start of the method? 16:05:34 flacoste, because then the user of the API has to know about the internal rules 16:06:01 there is another possibility 16:06:34 have DB.get_raw_events_by_user() and DB.get_raw_events_by_project() be thin wrapper around DB._internal_get_raw_events(project, user) 16:07:42 flacoste, yes, we could implement it that way. Whether or not that makes sense is left up to the engine author. I was trying to create an API that was consistent from the outside perspective without considering implementation details. 16:08:27 dhellmann: and I think you achieved this goal quite well 16:08:41 dhellmann: then what you have is probably good enough 16:08:54 should we move on? 16:09:00 we'll implement one or two and see if we can improve on the API after that 16:09:04 yes 16:09:09 #topic nijaba: to prime the doc once info received from dhellmann 16:09:09 I unfortunately did not have time to complete this task. Reassigning to next week 16:09:09 #action nijaba: to prime the doc on plugins 16:09:34 sorry, did have to cover an event this week, which hate a lot of my time 16:09:47 s/hate/ate/ I hope 16:09:56 righhhhhtttt 16:10:01 ;-) 16:10:04 depends on the event :-) 16:10:09 hehe 16:10:14 moving on 16:10:27 #topic nijaba: to prepare incubation application for review at the next meeting 16:10:27 so I did prepare this, you can review my work at: 16:10:27 #link http://wiki.openstack.org/Projects/IncubatorApplicationCeilometer 16:10:27 any comments, suggestions or remarks? 16:10:53 I haven't had a chance to review it, yet. I will try to do that this week. 16:10:59 so I am going to give you a few minutes so that you have time to read 16:11:15 or should we mark it as an action for next week? 16:11:40 can we discuss next week? or do we need to submit it before then? 16:11:50 nope, no hurry I think 16:12:44 #action during next week meeting we will vote on the Incubation application 16:13:08 #topic dachary: talk to Dragon about SystemData / ceilometer and try to create cooperation 16:13:08 dachary not beeing around I'll push this to next week's meeting 16:13:22 #action dachary: talk to Dragon about SystemData / ceilometer and try to create cooperation 16:13:32 #topic dhellmann: to talk to Quantum devs about integration with ceilometer 16:14:03 I have discussed this with my coworker privately, but have not approached the Quantum devs publicly, yet. 16:14:13 #action dhellmann: talk to Quantum devs about integration with ceilometer 16:14:29 #topic dachary: to talk to swift devs about integration with ceilometer 16:14:29 dachary not beeing around I'll push this to next week's meeting 16:14:45 #action dachary: to talk to swift devs about integration with ceilometer 16:14:57 #topic nijaba: to talk to cinder devs about integration with ceilometer 16:14:57 I did start the discussion with them on the ML. jgriffith said he would be joining the meeting today to start discussing 16:15:13 jgriffith: ping? 16:16:27 ok, it seems that he is not around atm. We'll come back to it eventually 16:16:47 #topic jd___: to talk to glance devs about integration with ceilometer 16:17:08 I did it at https://lists.launchpad.net/openstack/msg13331.html 16:17:30 conclusion is that we seem to doing the right thing so far :) 16:17:48 yes, I saw that. Thank for the email template I reused for initiating the conversion with cinder, btw ;) 16:17:57 hehe I saw that too :-) 16:18:11 any comments on this? 16:18:40 did I see someone suggest tying in via the client library? or did I misunderstand a response? 16:18:58 dhellmann: that was about cinder I believe 16:19:24 ah, ok 16:19:45 I've been dealing with some local issues, so I'm a little behind on email. Did you explain why that wouldn't work? 16:19:56 dhellmann: we could poll cinder via the client library, but volume creations/del could be nice events to catch 16:20:13 ah, polling via the client does make some sense, if it gives the data we need 16:20:57 we just need to check that the client lib does have the requested data ;) 16:21:05 ok, it sounds like things are moving in the right direction. -- true :-) 16:21:23 I would agree 16:21:42 #topic Status of the essex compatibility effort that jd is leading 16:22:30 nijaba: sorry, was stuck in a meeting 16:22:47 that may get easier, once we move to the openstack.common RPC libraries (in addition to the other parts of common we're already using) 16:22:56 jgriffith: np. Let's finish on this topic and we'll come back to you in a sec 16:23:37 jd___: do you have an update about essex compat? 16:24:22 yeah, my patches for testing have been merged 16:24:32 but i'm not sure they are set up in the real jenkins yet 16:24:38 cool! any blockers found? 16:24:49 not so far, for the part being tested at least :) 16:25:07 any action on that topic for next week? 16:25:40 we should add some more tests, at least simulating the daemon launch because I know this is going to fail on essex 16:26:03 and checks that my openstack-ci stuff are working :) 16:26:19 jd___: Feel free to add #action for this :) 16:26:31 jd___ can we crib test infrastructure from the nova tests for Service? 16:26:49 dhellmann: I hope so! 16:26:56 :-) 16:27:00 #action jd___ check that openstack-ci runs the tests for Essex 16:27:11 #action jd___ add some tests on daemon launching 16:27:25 thanks. Shall we get back to cinder? 16:27:42 yep 16:27:49 #topic discussion about cinder integration 16:27:59 jgriffith: thanks for joining! 16:28:21 Sure... sorry I was late 16:28:46 jgriffith: so, we think we could build a ceilmoter agent that would poll the cinder client for volume usage per user 16:29:01 jgriffith: any pointer on what call we should make? 16:29:21 So I think that would be doable in terms of the client. We might want to just implement a specific call via extension? 16:29:38 That way providers that are worried about security etc can choose to not load 16:30:06 oh, you mean that the call would be open to anyone? 16:30:37 Yeah, probably...not sure how else to implement it 16:30:43 this is more of an "admin" feature for internal use, although I can see the information being useful to end-users if they are restricted to asking about their own account(s) 16:30:59 I would rather find something that would not expose this data by default to somthing else than ceilometer 16:31:03 dhellmann: got ya, but not sure how you'd limit that, unless you do it via the context? 16:31:23 jgriffith, we're getting into an area of OS I 16:31:26 'm not familiar with 16:31:39 nijaba: I would prefer that as well 16:31:40 I know there is a way to separate the public and admin APIs, but I don't know how 16:31:44 jgriffith: context is probably fine, you use a policy engine too? 16:31:53 dhellmann: Ok, I can look into that 16:32:03 jd___: Yes, we could set that up as well. 16:32:21 might be best to get some input from folks on the best way to coordinate and make this happen 16:32:37 also, need to be honest about resources on the cinder team... they're a bit thin 16:32:52 I guess the ml would be the best place to ask for this? 16:32:58 So depending on how heavy a lift we're looking at on the cinder side it could dictate timelines 16:33:18 nijaba: Yes, I think it's best to get it out on the ML 16:33:20 jgriffith, I'm sure we could contribute resources for implementation if it comes down to that 16:33:37 nijaba: It's painful at first with all of the feedback but it should give us some good direction 16:33:43 dhellmann: excellent 16:33:59 we're expecting to do that for all of the integration work, to varying degrees 16:34:02 who wants to take the action to bring the question to the ml? 16:34:44 ok, I guess it will be me then? 16:34:58 unless jgriffith can do it? 16:36:00 #action nijaba to question best method to authenticate admin client calls from ceilometer to cinder (and other projects) 16:37:13 jgriffith: another point that we could want to capture are volume events, such as creation/deletion etc... do you publish them currently somewhere? 16:37:32 nijaba: No, we don't 16:38:03 So we keep things in the db like creation/deletion time but don't actually capture the events anywhere that I'm aware of 16:38:06 ok, so that would be something else we would have to look into 16:38:19 is that a conscious decision, or something you just haven't gotten to yet? 16:38:37 IOW, if we contributed some patches to emit notifications, would that be OK? 16:40:52 jgriffith: would you like us to join one of your meeting to discuss this further? 16:42:35 ok, I think jgriffithmaybe experiencing some technical difficulties 16:42:50 should we tab this and move it to the ml as well? 16:43:14 yes 16:43:15 +1 16:43:37 #action nijaba to include adding events to cinder to previous action 16:43:42 sorry... booted out 16:44:09 nijaba: Maybe next wed, let's talk offline between now and then and have a game plan though 16:44:44 jgriffith: sounds good to me. 16:44:53 nijaba: great 16:44:58 jgriffith: when is your meeting on wed? 16:46:01 #link http://wiki.openstack.org/NovaVolumeMeetings 16:46:19 so same time as ours, but on wed 16:46:33 who will be able to join? 16:47:13 I should be able to join a little late 16:47:24 ok great. I'll be there too 16:47:41 let's move on to Open Discussion 16:47:55 #topic open discussion 16:48:16 anything else someone wants to bring up? 16:48:24 nope 16:48:25 nijaba: 1600 UTC 16:48:58 jd___, how goes the pep8 / conf patch work? 16:49:09 dhellmann: did not check yet :( 16:49:18 ok 16:49:20 I need to upgrade pep8 16:49:27 and for whatever reason my pip fails! 16:49:32 jgriffith: great, so dhellmann and I will be joining and I'll initiate a private thread between the 3 of us. thanks 16:51:26 #action dhellmann and nijba will be joining and nijaba will initiate a private thread with jgriffith 16:51:44 ok, looks like we are done with the agenda for today 16:51:50 thanks everyone for joining! 16:52:07 good meeting, we ended early :-) 16:52:14 #endmeeting