15:00:24 #startmeeting Ceilometer 15:00:25 Meeting started Thu Mar 7 15:00:24 2013 UTC. The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:26 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:28 The meeting name has been set to 'ceilometer' 15:00:33 #meetingtopic Ceilometer 15:00:41 #chair dhellmann 15:00:42 Current chairs: dhellmann 15:00:47 #link http://wiki.openstack.org/Meetings/MeteringAgenda 15:00:52 ATTENTION: please keep discussion focused on topic until we reach the open discussion topic 15:00:57 Please raise your hand if you are here for the ceilometer meeting. 15:00:58 o/ 15:00:59 o/ 15:01:01 o/ 15:01:01 o/ 15:01:01 o/ 15:01:03 o/ 15:01:03 o/ 15:01:07 o/ 15:01:08 o/ 15:01:31 hi, gordc, are you here for the ceilometer meeting? 15:01:47 let's get started 15:01:49 #topic Review last week's actions 15:01:53 #topic nijaba to check room allocation for ceilometer during summit 15:01:55 hi dhellmann, yes. just checking in. 15:02:04 great, we're just getting going 15:02:28 nijaba isn't able to make the meeting today, and I didn't get an update from him, so I will put this on the agenda for next week 15:02:30 #action nijaba to check room allocation for ceilometer during summit 15:02:38 #topic nijaba to start a brainstorm wiki for a tag line on the tshirt 15:02:43 #link https://wiki.openstack.org/wiki/Ceilometer/TagLine 15:02:50 o/ 15:02:51 #info done 15:03:08 if you have proposals for a tagline, please add them to that wiki page 15:03:16 #topic Bug day results 15:03:21 o/ 15:03:33 we had our second bug squashing day on tuesday 15:03:47 it seemed to go well, there were a lot of changesets up for review 15:04:01 did anyone count them? 15:04:36 ok, perhaps not 15:04:38 jd__: has been submitting like 5 at a time 15:04:51 we should be able to get those stats 15:05:08 yes, he had several related changes stacked up :-) 15:05:18 i opened a new bug instead of fixing any :P 15:05:34 maksimov: we'll take it! 15:06:01 does anyone have comments about how to improve the process for next time? 15:06:29 probably a good idea to have a discussion a day earlier 15:06:38 yep 15:06:50 timing was definitely better this time round 15:06:55 Is the bug squashing day target for take ownership of the bug or fix it on that day? 15:06:58 I tried to do a little triage work, but discussion would be good 15:06:59 (in terms of closeness to a release deadline) 15:07:08 llu-laptop: both or either 15:07:18 eglynn: +1 15:07:48 I think it also helped that we were in feature-freeze, so there was less temptation to work on new things. :-) 15:07:57 some bugs are not easy to do. Like the metaquery for sqlalchemy which jd took 15:07:58 true that 15:08:17 what do you think about introducing week-long bug sprints at a couple of spots in our schedule for H? 15:08:27 maybe leading right up to milestones, for example? 15:08:32 the perfect bug for a day of squashing is bite-sized and self-contained 15:08:37 which is limiting 15:08:54 so yeah, a weak long bug sprint sounds ideal 15:08:56 week-long sprint is good 15:09:02 +1 for week-long sprint 15:09:13 ok, we'll leave that for our next PTL to organize, then :-) 15:09:13 especially for those who are not 100% devoted, but still want to participate 15:09:17 it would also give folks the flexibility to dip in and out 15:09:26 yep, exactly 15:09:36 +1 15:09:40 #agreed introduce week-long bug sprints during the H cycle, details to be determined 15:09:41 +1 15:10:23 I believe quantum has a feature freeze ~1 week before each milestone, so maybe we can verify that and duplicate what their team is doing 15:10:28 ok, moving on 15:10:32 #topic Removal of unactive core developers 15:10:40 It is proposed that we remove Loic Dachary, Francis J. Lacoste, and Graham Binns from the "core" team. 15:10:43 My understanding is their status can easily be restored. 15:10:55 what's our definition of inactive? 15:11:01 o/ 15:11:03 no patches in previous release cycle? 15:11:13 or no reviews? 15:11:16 well, I'm not sure that they have contributed during grizzly 15:11:22 k 15:11:26 for core, reviews are (IMO) the most important contribution 15:11:35 dhellmann: agreed 15:11:42 I'm not 100% sure of the process for making the updates, but I think if everyone agrees we can leave it to nijaba to handle. 15:11:51 for nova it's # reviews in 30 days 15:12:00 and, as I mentioned, their status can easily be reinstated by their asking 15:12:00 (at least 10 required) 15:12:04 that's fair 15:12:21 any objections? do we need to vote on it? 15:12:25 sandywalsh: we're smaller, so a lower threshold seems reasonable 15:12:39 dhellmann, sure 15:12:40 I'm not sure of the voting process for that 15:12:51 I don't think we have a quorum of core contributors today 15:13:14 if there are no strong objections, I propose we just say we've agreed and let nijaba handle the details when he gets back 15:13:19 fair enough (I don't object to the removal, just wondering about the process ...) 15:13:22 what's the benefit of removing? does this free up a quota for new core? 15:13:34 or is there a quota 15:13:58 maksimov: no, there is no quota 15:14:27 but if they are not contributing, I think we want them off of the core list so we know who *is* an active contributor 15:14:47 ok so 15:14:48 just housekeeping really I guess, also ... pour encouragez les autres 15:14:58 right 15:15:38 eglynn: is that latin? 15:15:40 you know, I guess it makes voting in new core members easier, too, since the voting pool is limited to the active contributors 15:16:01 llu-laptop: french (to encourage the others) 15:16:06 llu-laptop: French, I'm standing in as the token Frenchman today ;) 15:16:15 :) 15:16:44 so if there are no strong objections, I will mark us agreed and let nijaba take care of it? 15:16:58 looks like I can learn my 2nd foreign language here. addtional benifit ;) 15:17:02 agreed 15:17:08 +1 15:17:24 dhellmann, just so I'm clear, are you suggesting that only patches are meaningful vs. just reviewing? 15:17:37 sandywalsh: the opposite, for core 15:17:41 the opposite I thought 15:17:44 yep 15:17:47 k, cool .. good 15:17:49 well, not the opposite, but reviews are more important 15:17:56 patches are definitely important, too! 15:18:03 +1 15:18:08 #agreed remove Loic Dachary, Francis J. Lacoste, and Graham Binns from the "core" team 15:18:16 #topic Release of python-ceilometerclient 15:18:39 just wondering what's the task list for such a release? 15:18:42 We need to prepare a release. I haven't had a chance to review the process for doing that. Is anyone else familiar with it? 15:18:51 nova allows a "fast track" for reinstated ... just start reviewing again regularly. No core vote required. 15:19:04 sandywalsh: right, I think we'd probably follow that process 15:19:30 #action dhellmann investigate the process for releasing a client library 15:19:49 I'm sure there's some automation around that, probably involving tagging 15:20:08 pushing up to pypi also? 15:20:14 yeah, jenkins does that part 15:20:17 k 15:21:10 I would like to propose that we use the semantic versioning scheme (1.0.0), rather than date-based (2013.1) because my understanding is the new python packaging tools will eventually not work with date-based releases. 15:21:32 there was some discussion of this related to oslo.config recently on the dev mailing list 15:21:54 it seems like, since this is our first release, we should try to start out down the right path, instead of having to change it later 15:22:23 any objections or questions? 15:22:29 dhellmann, better check with ttx on that one 15:22:29 agreed. We don't want follow oslo.config. 15:22:41 sandywalsh: yeah 15:22:42 I think the other python-*clients already go with x.y.z as opposed to YYYY.x 15:23:26 semantic versioning is fine with python client libs 15:23:31 eglynn: a sample of size 1 says you may be correct 15:23:40 ttx: thanks! 15:23:42 Should the client follow the same milestone as the main project? 15:24:21 llu-laptop: since it doesn't follow the same versioning scheme, and it is supposed to maintain backwards compatibility, I think the idea is to be able to release more frequently, as needed 15:24:24 llu-laptop: they're decoupled for the other projects 15:25:07 for example i see python-swiftclient 1.3.0, python-novaclient 2.11.1 15:25:10 llu-laptop: sometimes causes an issue, e.g. when a new novaclient include calls that require new-ish support in nova core 15:25:44 are there any missing features that would preclude a release? or any critical bugs? 15:26:14 also another thing to note for the clients is that there's no stable branch 15:26:29 (so any fixes wait for the next full release) 15:26:50 eglynn: yes, but we can release whenever we need to, right? 15:27:03 dhellmann: yep 15:27:19 so the "wait" may be until "tomorrow" :-) 15:27:27 I guess :) 15:27:32 are there plans to merge the client into openstackclient or is ceilometer going to remain separate? 15:27:59 gordc: I plan to get them merged 15:28:00 is this an old one? https://pypi.python.org/pypi/ceilometerclient/0.1 15:28:18 maksimov: yes, that was a prototype that we wrote at dreamhost 15:28:31 I always get confused between python-novaclient and novaclient ... is one pip and one distro? 15:28:34 oic - 'pre-alpha' 15:28:47 it predates asalkeld's work on the official client 15:29:07 sandywalsh: I'm not sure I've see novaclient. I think the package name is python-novaclient 15:29:19 well, the "dist" name is python-novaclient and the python package is novaclient 15:29:36 maksimov: yes, a completely different (and now abandoned) code base 15:29:48 ok, there was two for a while, but I think they've cleaned that up 15:29:54 sandywalsh: ah 15:30:10 the whole list https://pypi.python.org/pypi?:action=browse&c=583 15:30:10 so, back to our client: does anyone have any bugs we definitely need to fix before a 1.0 release? 15:30:24 and, now that it comes up, should this be 1.0? 15:30:43 I think it should, but does anyone disagree? 15:30:47 keystoneclient is still 0.2.2 15:30:51 yolanda's https://review.openstack.org/23549 should probably go in 15:31:06 eglynn: yes, definitely 15:31:08 I don't think so ... I think we're going to have some big changes in the next release, but it's just a number 15:31:12 we're just waiting for tests for that 15:31:27 sandywalsh: big changes in the client? 15:31:34 can we align 1.x vs 2.x with use of v1 vs v2 perhaps? 15:31:51 maksimov: I don't think we need to do that 15:32:00 the client we have already supports both apis 15:32:05 will it support both? 15:32:06 dhellmann, possibly all over (I'm thinking the new data types if we go that route) 15:32:14 maksimov: other clients support multple API versions at once 15:32:25 oh ok 15:32:26 maksimov: e.g. glance --os-api-version 2 15:32:31 sandywalsh: those sorts of changes would mean a v3 api, it sounds like. a client 2.0 could support the new api, right? 15:32:44 but, we can't worry about what "might be coming" ... we just have to put a mark in the ground. 15:32:51 sandywalsh: +1000 15:32:51 version 1 to me says "it's ready for production" 15:32:59 is cm ready for production would you say? 15:33:13 the client is as ready as the rest of it :-)( 15:33:32 * dhellmann is channelling nijaba with typos today 15:33:50 I have a bug on the install...https://bugs.launchpad.net/bugs/1118780 15:33:52 Launchpad bug 1118780 in python-ceilometerclient "The ceilometer python client fails install due to required packages" [Undecided,New] 15:33:54 I think that's core's call if it's ready for the big dance 15:34:08 version 1 also means "we're locking stuff down" 15:34:27 Any chance to see that resolved before the rev to 1.0? 15:34:50 nealph: that looks like a bug in the ubuntu package of the client, not the client itself, right? 15:34:57 IOW, if we push a package to pypi, someone could install it from there 15:35:02 Yep, I'd say. 15:35:26 Willing to try it there, sure. 15:36:13 ok, so it sounds like we mostly agree to use 1.0 and we want to wait for yolanda's fix to be merged before the release 15:36:33 cool 15:36:42 #agreed we need https://review.openstack.org/23549 merged before releasing the client 15:36:54 #agreed use semantic versioning, starting with 1.0.0 15:37:02 #topic Planning to attend the ODS 15:37:09 so, who will be in portland in April? 15:37:10 o/ 15:37:13 o/ 15:37:15 o/ 15:37:21 o/ 15:37:21 asalkeld: o/ 15:37:25 I planned to, but waiting for my visa 15:37:40 what's the sign for possibly? 15:37:44 (and 3 more of us from RAX that are working on CM) 15:38:03 will be in portland in April 15:38:11 maksimov: "possibly" :-) 15:38:18 so that ^^ 15:38:25 ok, good 15:38:49 I think we talked last week about trying to get together for dinner one evening, and we're just waiting for the official schedule so we can decide which party to skip :-) 15:38:51 o/ 15:39:02 o/ for portland as well. 15:39:20 didn't get approval to travel, so DanD will have to represent. 15:39:25 o/ 15:39:49 nealph: do you know if they're going to have webex and irc in the rooms again? 15:39:56 * sandywalsh has to jump off ... good luck with the release all 15:39:59 there are ~15 ceilo sessions proposed so far ... http://summit.openstack.org 15:40:05 Hoping so... 15:40:09 possibly... if budget gets approved... so in other words.. no. 15:40:15 gordc: :-( 15:40:20 o/ 15:40:26 ok, let's talk sessions 15:40:26 But not sure. Who can find out? 15:40:27 so maybe we'll end up needing a second day ... 15:40:29 #topic Submitting ODS sessions & blueprints 15:40:37 Please remember to submit summit sessions for any blueprints you want worked on during Havana 15:40:41 #link http://summit.openstack.org/ 15:41:09 are there any topics that you think need to be discussed, but that you're not comfortable proposing as a session leader? 15:41:36 FWIW, if you want a topic, that doesn't imply that you have a solution already 15:41:37 I am submitting a session on ceilometer and healthnmon integration 15:42:00 Divakar: excellent 15:42:03 Divakar: looking forward to that 15:42:09 healthnmon for sure:) 15:42:10 Divakar:this is a good one! 15:42:11 Divakar, +1 15:42:20 great 15:42:35 Region and availability zone support 15:42:54 epende: I believe there is a session that covers those... 15:43:03 nova-cell? 15:43:06 there's one on cells http://summit.openstack.org/cfp/details/63 15:44:15 the blueprint for http://summit.openstack.org/cfp/details/75 mentions them 15:44:37 epende: we also have a touch of that in our "advanced billing models" session http://summit.openstack.org/cfp/details/79 15:45:31 can someone remind me again the deadline for suggesting topics? 15:45:41 end of moth 15:45:46 *month 15:45:51 I did notice what I thought was a bit of overlap in some of the topic areas, so everyone please review the list with that in mind, too. 15:46:02 shengjie: (but the sooner the better) 15:46:09 eglynn: thanks 15:46:20 we will have limited space and time, so if we can combine sessions that will help ensure everyone's ideas are heard 15:46:28 what is the process for combining sessions when there is overlap? 15:47:01 PTL knocks heads together? 15:47:01 DanD: approach the other proposer and get agreement, then tell nijaba (or the new PTL) 15:47:04 is zehndton around? Do you want to talk about the physical monitoring? 15:47:10 here 15:47:14 I think the PTL has a way to either merge or close sessions in the tool 15:47:53 speaking of merging sessions... 15:47:55 #topic Planning ODS sessions with other teams 15:48:06 I thought it would be a good idea to approach the documentation and QA teams for help getting started working with them, now that we are integrated. Any thoughts? 15:48:23 healthnmon covers the model and approach for physical server monitoring... 15:48:42 yep, definitely a good idea to talk to the tempest folks 15:49:00 integrate ceilometer into tempest and CI? 15:49:08 that is a good idea, I think. 15:49:10 we're already doing CI, but tempest, yes 15:49:16 Divakar: monitoring wise, i meant to ask what's the stories with all the synaps bps ? 15:49:16 I've created a bp https://blueprints.launchpad.net/ceilometer/+spec/more-qa-test, but no input there 15:49:40 shengjie: got it 15:49:51 llu-laptop: do you want to propose a session, too? 15:50:03 shengjie: we looking at a different mor elightweight approach that synaps 15:50:10 * dhellmann reminds everyone that you must create a session proposal separately from the blueprint 15:50:11 s/that/than/ 15:50:34 I'm not confident holding the tempest session, i think we should contact the qa team first 15:50:51 llu-laptop: well, the idea would be to have that conversation there in the room together :-) 15:50:57 I can lead the session, if you would prefer 15:51:06 dhellman: great 15:51:19 #action dhellmann propose an ODS session for tempest integration 15:51:29 does anyone want to approach the documentation team? 15:51:44 eglynn:k, i'll take it offline with u :) 15:51:51 also, do we want to see if the heat team would like to participate in these sessions? 15:52:00 healthnmon with tempest would that be of interest? 15:52:39 dhellmann: yep, we need to tie down the alarming/heat interaction model 15:52:41 Divakar: you can propose the session, but I suspect we'll want to wait until healthnmon is incorporated into ceilometer in some fashion to start doing that 15:52:48 (though that may occur in adavnce of the summit) 15:52:58 eglynn: I mean specifically the doc and tempest sessions 15:53:05 dhellmann: a-ha, got it 15:53:08 dhellmann: sure 15:53:21 both teams would benefit from the instruction, so save the doc and qa team's time 15:53:31 agreed 15:53:37 eglynn: can you talk to heat? 15:53:44 dhellmann: yep 15:53:57 #action eglynn invite heat team to participate in doc and qa sessions at ODS 15:54:07 #action dhellmann approach documentation team about a joint session at ODS 15:54:22 OK, getting close to end of time 15:54:23 #topic PTL elections 15:54:30 We have 2, I think, candidates now (jd__ and eglynn). 15:54:50 If anyone else is planning to run, I think the deadline for announcing is coming up 15:55:15 #topic Open discussion 15:55:24 who would know we will have webex or similar access to the ODS 15:55:45 nealph: ttx may know, but it might be too early to tell 15:55:47 stefano perhaps? 15:55:56 last time they did announce it on the mailing list, IIRC 15:56:21 okay, will be watching for it...will wait a couple of weeks before asking around. 15:56:34 good plan 15:57:00 is there anything else for today? 15:57:05 is there any daylight saving time in US since next week? any impact for meetings? 15:57:13 3/10 15:57:19 er 4/10 15:57:40 3/10. Time changes for most US. 15:57:43 * dragondm is confused 15:57:44 shanewang: the official meeting times are UTC, which doesn't have DST 15:57:59 ok 15:58:07 so, do the time conversion for the date of the meeting, and you *should* get the right answer :-) 15:58:28 I have 2 more things 15:58:33 1: Is anyone going to PyCon? 15:58:41 that's PyCon US, next week 15:58:58 2: We have 13 changesets in the queue. Please review! 15:59:31 i think most of them are blocked by the oslo.config 15:59:54 llu-laptop: yeah, I think your fix will unblock that. did you see my comment? 16:00:08 dhellman: I've updated patch 3. 16:00:21 llu-laptop: ok, I'll go look and fast-track approve it to unblock the queue 16:00:37 * dhellmann is planning to help with the common requirements project next release to avoid these issues 16:00:47 so, nobody is going to pycon? 16:00:56 nope, sadly ... 16:00:57 alas. 16:01:05 ah, well 16:01:15 ok, I think our time is up 16:01:24 thanks for a good meeting, everyone! 16:01:29 thanks 16:01:33 thanks all! 16:01:41 thanks 16:01:41 thanks and bye 16:01:46 #endmeeting