15:00:12 #startmeeting ceilometer 15:00:13 Meeting started Thu Dec 11 15:00:12 2014 UTC and is due to finish in 60 minutes. The chair is eglynn. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:16 hey y'all 15:00:18 The meeting name has been set to 'ceilometer' 15:00:26 o/ 15:00:27 hello 15:00:29 o/ 15:00:31 o/ 15:00:45 o/ 15:01:02 o/ 15:01:07 #topic kilo-1 BPs 15:01:11 #link https://launchpad.net/ceilometer/+milestone/kilo-1 15:01:30 o/ 15:01:31 o/ 15:01:34 o/ 15:02:02 BPs are looking relatively good, assuming we can get the last few over the line by early next week 15:02:03 <_elena_> o/ 15:02:22 the milestone tag will be cut sometime between Tuesday and Thurs next week 15:02:33 (when we're happy to pull the trigger on it) 15:02:46 is the hope that the declarative test code will be done by end of kilo-1? 15:03:07 cdent: would you be able to get that spike into a proposable patch for declarative-http-tests? 15:03:33 it's blocked on me being ignorant about how to get testresources to do what I want 15:03:42 cdent: so, punt it kilo-2? 15:03:57 If I can throw away some of the requirements about test isolation from various folks I could get a working version relatively easily 15:04:29 cdent: cool, if that's enough to declare partial victory 15:04:49 cdent: ... so hold off punting for a couple days, then make a call? 15:04:50 I'll take a closer look after the puppet stuff 15:04:55 make sense yes 15:05:00 cdent: cool, thank you sir! 15:05:59 gordc, DinaBelova, fabiog: BPs looking good for kilo-1? 15:06:08 eglynn, yeah, it looks so 15:06:16 eglynn: I will address your comments today 15:06:22 eglynn, as for mine one - I need code reviews + will fix moment you mentioned 15:06:23 I need review for rally stuffs :) 15:06:41 sileht, yeah :D finally I've added +2 after some research :) 15:06:42 sileht: I +A'd that one earlier, should have landed :) 15:06:52 sileht, xmas for u :) 15:07:21 DinaBelova: thanks! 15:07:22 eglynn: coordination work is looking ok. just addressing reviews 15:07:30 fabiog: excellent :) 15:07:34 gordc: nice one :) 15:07:42 reviewers are too busy with their one changes and don't review :D 15:07:46 eglynn, DinaBelova cool I haven't seen it 15:08:00 eglynn, I have already one +2 for the infra part 15:08:13 sileht, you may ping SergeyLukjanov :) 15:08:17 DinaBelova: i'm saving review mode for k-3 15:08:19 and try to grab second one 15:08:24 gordc :D 15:08:29 sileht: a-ha, I was just talking about this one https://review.openstack.org/132649 (the ceilo part) 15:09:17 I have 2 +2 now on the infra part: https://review.openstack.org/#/c/132650/ 15:09:32 SergeyLukjanov, hehe, thanks :) 15:10:26 hmmm, do the infra folks normally require >2 +2s before approving? 15:10:40 eglynn, I suppose they were waiting for +1 from Boris 15:10:46 he set -1 firstly 15:10:50 and then changed mind 15:10:51 DinaBelova: a-ha, got it, thanks :) 15:12:00 anything else on kilo-1? 15:12:15 ... other than the usual request to prioritize your review time on k1-targetted patches over the next few days 15:12:21 ... pretty please :) 15:12:40 * DinaBelova nods 15:12:49 * ildikov too 15:12:56 #opic DocImpact 15:13:01 #topic DocImpact 15:13:12 ildikov: the floor is your's :) 15:13:16 so just a quick reminder for the reviewers 15:13:24 eglynn: thanks :) 15:13:51 I just wanted to ask everyone that please check if the DocImapct flag is there for those patches where config changes appear 15:14:06 or those ones that affect the content of the Ceilo admin guide in OS-manuals 15:14:31 ildikov, btw, what should I do with merge-agents change? I made separated commit with documentaiton changed -> should I set this flag in feature change or in the docs one? 15:14:31 ildikov: can you explain what workflow that tag in the commit message actually triggers? 15:14:49 if you're not sure, then it's still better to have that flag, as it's easier to invalidate a bug, then figure out what's missing frm the docs 15:14:53 * SergeyLukjanov here 15:15:09 re 132650 I could approve it if you folks are all for it 15:15:10 SergeyLukjanov, may you take a look on the https://review.openstack.org/#/c/132650/ 15:15:10 SergeyLukjanov: just discussing https://review.openstack.org/132650 15:15:22 SergeyLukjanov, we are :) 15:15:30 oh, I see +1 from boris-42 15:15:36 DinaBelova: if you have more patches for one change, the where you added docs, it's the best IMHO, but if you have a topic, then it can be found anyway 15:15:37 SergeyLukjanov: (i.e. now that Boris has +1'd, good to fly?) 15:15:43 approved 15:15:48 ildikov, a-ha, thanks 15:15:49 SergeyLukjanov: thank you sir! :) 15:15:54 SergeyLukjanov, thanks :) 15:15:59 * SergeyLukjanov disappeared 15:16:00 eglynn: sure, so the point is that a Bug report is generated for those patches after they got merged 15:16:18 the link of the patch is added, just like a ceilometer tag 15:16:32 so the changes that impacts docs can be tracked this way 15:16:56 ildikov: cool, and that bug is auto-assigned to someone on the core docs team, or expected to be handled by the ceilo team? 15:16:59 this is the process so far in nutshells 15:17:18 of course, if you can encourage people to fix the OS-manuals docs, then it's even better ;) 15:17:34 but start with the DocImpact flag is fine also 15:17:34 ildikov, lol 15:17:41 ok, will add one 15:17:48 DinaBelova: thanks 15:17:57 expected by the ceilo team mostly eglynn 15:18:24 ildikov: a-ha, k ... so the expectation is that one of our team will propose the OS-manuals patch for the auto-generated bug 15:18:28 we are considering changing where DocImpact logs bugs, but haven't gotten that far along 15:18:32 eglynn: Ceilo team, so nowadays it means me :) 15:18:38 go go ildikov :) 15:18:54 eglynn: I'm trying to keep the number of bugs low as a hopefully good start as a docs liason 15:19:05 :) 15:19:11 ildikov: I'll try to help out with that too ... my eyes have stopped bleeding when I look at docbook markup :) 15:19:14 annegentle: :) 15:19:35 eglynn: the important part is to have changes tracked 15:19:49 ildikov: yep, fair point, agreed 15:20:16 eglynn: cool, so basically that's all, I just wanted it as a heads up 15:20:34 ildikov: thanks, that was a useful clarification of the process 15:20:44 #topic TSDaaS/gnocchi status 15:21:19 eglynn: /me thanks in advance for the extra care of patches on review :) 15:21:34 https://review.openstack.org/#/q/project:stackforge/gnocchi,n,z 15:21:46 lots of work from jd__ on polishing the RBAC logic 15:21:49 annegentle: tnx for helping out a bit with additional info :) 15:22:03 also a nice patch from sileht with a ceph storage driver 15:22:16 also finished the doc auto generation from real data 15:22:20 (waiting for review :) 15:22:32 jd__, wow, missed this change 15:22:38 need to looks there for sure 15:22:53 DinaBelova: (later related topic on agenda for an alternative OPW topic for nellysmitt) 15:23:01 eglynn, yeah :) 15:23:06 I already proposed one btw :) 15:23:06 :) 15:23:16 jd__: coolness, thanks! 15:23:17 jd__, image resource one? 15:23:22 DinaBelova: yes 15:23:31 jd__, yes, that's the good start anyway 15:23:41 but I suppose we need some more global one here as well 15:23:45 laters, sorry 15:25:14 jd__, also ityaptin and I are thinking about background downsampling/pre-arrgegation process for opentsdb and probably carbonara as well 15:25:28 jd__, probably we'll need soe your advice next week :D 15:25:30 and some discussion 15:25:32 sure :) 15:25:32 :) 15:25:36 jd__, thanks! 15:25:39 sileht: I owe you a review on https://review.openstack.org/125572 ... will get on it after this meeting 15:26:16 DinaBelova: so opentsdb has no native downsampling as yet? 15:26:39 * eglynn has vague memory of a proposal to add it 15:26:49 eglynn, nope, I've mentioned this - they think that that's good enough task for some usual co-processor job 15:27:13 eglynn, and that's why they don't have this implemented yet 15:27:34 I remember seeing somewhere that opentsdb folks have plans for this - but in very-very long-term thing 15:27:42 If I'm not mistaken 15:28:10 probably we can have kind of experiment here, and then try to push this code back to opentsdb itself, we'll see 15:28:11 DinaBelova: a-ha, cool, got it ... I had previously thought this would be added internally within the DB, as opposed to within gnocchi 15:28:34 eglynn, I was thinking about this as well, but that seems to be kind of long-term proposal 15:28:46 eglynn, and also that might be useful for carbonara as well 15:28:55 to increase its performance 15:29:26 DinaBelova: cool enough ... yep, could be advantageous if carbonara could leverage the async downsampling as well 15:29:33 eglynn, a-ha :) 15:30:09 k, move on from gnocchi? 15:30:36 #topic Event/notification pipeline configurations 15:30:48 nealph: what had you in mind here? 15:30:57 So, https://review.openstack.org/#/c/138904/ & https://review.openstack.org/#/c/128411/5/specs/kilo/notification_filter.rst both point to some changes in event/notification config. My main concern is config proliferation...I thought it would be good to hash out a bit here, and/or decide to take offline. 15:31:36 As I noted to gordc, they 15:31:54 're pointing at different pipelines, but the concern is still there for me. 15:32:22 nealph_: i think they address different issues. as i understand it, fabio's work is just for samples while my spec is for events. 15:33:02 nealph_: ie. a notification comes in and it gets converted into x samples (fabios work) and 1 event (my spec) 15:33:35 gordc: I think we could also load the event_pipeline in the database in the future, do you agree? 15:33:48 fabiog: yep 15:33:56 fabiog, I suppose that's lle logical, yeah 15:33:58 nealph_: is the concern mainly that the pipeline.yaml is becoming overly-complex? 15:34:21 fabiog: not sure what the scope of db work is... if it's just for pipeline or for other conf files as well? 15:34:27 (why aren't the pipelines kept a keystone-known uri?) 15:34:35 s/a/at a/ 15:34:43 eglynn: not from gordc, as he's proposed a separate config. 15:35:19 but more to gordc's question: I think this would eventually roll into db too. 15:35:21 nealph_: a-ha, yes ... "a *new* pipeline.yaml" 15:35:29 gordc: as I know pipeline is a starting point as it is the best candidate to start with 15:35:50 gordc: yes, as ildikov noted. 15:35:50 cdent: a la the schemaURL endpoint proposed for the service catalog? 15:35:57 pretty much, yeah 15:36:24 cdent: well, I guess it's mainly an internal concern for ceilo, whereas IIUC the service catalog is more for outward-facing stuff 15:36:25 it just seems that if the goal is to have a central authority for pipelines that is easy to update, then a URI is a way to go 15:36:26 cdent: i think that was brought up at submit regarding schemas as well... i think keystone was not keen on maintaining that. 15:36:32 (for some definition of "outward") 15:36:35 gordc: with all conf the ultimate target. 15:36:49 involving keystone isn't really the important part: putting it at a URI is 15:37:15 sorry but before debating that it'd be nice IMHO if someone actually started to write the schema… 15:37:19 nealph_: cool cool. the pipeline i proposed is pretty much 80% of current pipeline... i just kept it separate so it didn't confuse people who didn't want events 15:37:32 If I'm running some tool I don't want it to have to make a db query to get pipeline info 15:37:38 jd__ that's coming kilo-2 15:37:45 cdent: oh someone started? 15:37:48 where is that? :) 15:37:50 sandy (who's sort of the main push) isn't free until then 15:37:56 jd__: i think we'll always stall at step 1... let's try jumping straight to step 3 :P 15:38:09 gordc: for now is only pipeline 15:38:12 gordc: +1 15:38:13 jd__: sandy has started discussing the distribution mechanism on the ML 15:38:22 yeah, that's what I'm saying 15:38:28 eglynn: do you have a ml link? 15:38:29 a lot of people talking, again, nothing is here yet :/ 15:38:41 we need victim-project :D 15:38:43 a lot of time wasted 15:38:45 jd__: sorry, not following.... 15:38:56 jd__: step 3! then we have to do step 1 and 2. 15:39:00 nealph_: http://lists.openstack.org/pipermail/openstack-dev/2014-November/051151.html 15:39:02 nealph_, jd__ is about notificaitons schema 15:39:41 nealph_: we're jaded people. 15:39:42 nealph_: yep, separate schemas ... I muddied the waters here by mentioning the schemaURL endpoint proposed at summit 15:39:47 I guess we should get back to the original topic as we have several more for today 15:40:01 DinaBelova: thx, tracking now. But not seeing the connection...eglynn: yep. :) 15:40:07 ildikov: sounds good 15:40:25 nealph_: i could discuss more about pipeline concerns post-meeting? 15:40:26 so, back to the point of "multiple pipeline.yaml"... 15:40:33 or now 15:40:36 lol 15:40:43 nealph_: the connection was the notion of a well-known URI exposed by keystone (presumably in the service catalog) 15:41:03 i 15:41:12 oops... ignore. 15:41:34 nealph_: is the concern that proliferating pipeline config now will make the later job of centralizing more difficult? 15:43:01 nealph_: that would be a fair concern 15:43:03 eglynn: well, yes, but really that prior to centralizing there's multiple maintenance points. 15:43:30 nealph_: ... so gordc needs to represent this events config somehow, and there's a limit to how much can be shoe-horned into a single config abstraction? 15:44:03 eglynn: i guess i could shove it into existing pipeline.yaml 15:44:15 hmm, there's also the event_definitions.yaml used by the event persistence logic 15:44:48 gordc: would it make any sense to put the event pipeline in there ^^^ also instead? 15:44:49 eglynn: nealph_: there would just be really subtle differences which may/maynot be hard to recognise what data type you're targetting 15:45:20 eglynn: i thought baout that... the def file is essentially a filter transformer 15:45:28 gordc: true that 15:45:46 eglynn: but that would mean by default we're taking in all the attrs of a notification... wihch could get verbose. 15:45:56 eglynn: possibly...deployer confusion is a concern here. 15:46:11 OK, all fair points 15:46:27 but prolly not going to be solved in the few remaining minutes of this meeting 15:46:33 i'm ok either way... i just went this path for now. 15:46:34 punt this discussion to gerrit? 15:46:36 so, gordc and I can take this to the ceilo room. yes? 15:46:45 eglynn: nealph_: sounds good 15:46:50 eglynn: we need to discuss the MidCycle 15:46:56 (after) eglynn: gerrit seems painful. 15:46:59 :) 15:47:09 eglynn: my window to organizing it is getting smaller :-) 15:47:16 I'm done. 15:47:17 #topic Final call on agenda for mid-cycle 15:47:54 sorry guys, I need to run now 15:48:14 ildikov: np! 15:48:24 I added two possible topics to the agenda, feel free to modify/remove it, those are just quick ideas from me what we could use that time for 15:48:53 fabiog: so do you essentially want confirmation that folks will attend before committing the resources on the HP side? 15:49:10 eglynn: well, at least to know we will go ahead 15:49:17 * ildikov will read the logs 15:49:18 laters 15:49:36 fabiog: OK, that's fair 15:49:39 eglynn: I cannot organize if nobody goes there or there is no interest in holding the meeting 15:50:07 fabiog: I'll commit to attending obviously since its relatively local for me 15:50:15 fabiog, I'll go through this agenda with all interested people here to see if I'll be able to attend 15:50:26 topic about batching looks pretty important to me 15:51:12 eglynn: considering that ildikov will go and jd__ can reach us anywhere we should have a quorum ... 15:51:35 fabiog: cool, so let's consider it confirmed :) 15:51:36 jd__: still trying to move to CA ;-) 15:51:43 just kidding 15:52:15 could someone remind me the URL of the agenda? 15:52:20 eglynn: thanks. I will post an update and some logistics as soon as I have it in the same etherpad 15:52:25 #link https://etherpad.openstack.org/p/galway-jan-2014-ceilometer-sprint 15:52:33 jd__ ^^ 15:52:40 DinaBelova: do we have time to also discuss "Alternative OPW topic for nellysmitt?" 15:52:49 (i.e in the next 7 mins) 15:52:52 eglynn, well, I suppose that's more offline task 15:52:56 as we have first step to do 15:53:01 that sounds pretty light to me 15:53:05 I mean adding images as resource to gnocchi 15:53:29 but I actually want to find something more global - dunno how to say better 15:53:37 I mean some feature to maintain 15:53:44 jd__: yes it is light right now, expecting more topics to be added though 15:53:56 jd__: (I've a couple in mind that I'll shortly) 15:54:03 so if someone is having any ideas - u're welcome :) 15:54:16 DinaBelova: yeah, adding image resource is a fairly localized change 15:54:34 DinaBelova: essentially follows the pattern for the instance resource 15:54:42 eglynn, yeah, indeed 15:54:58 probably some part of the batching process being implemented? 15:54:59 adding all needed resources to Gnocchi so it works with Ceilo/OpenStack ? 15:55:27 jd__, idegtiarov wanted to do that as well, afair - so they'll end really quickly :d 15:55:27 jd__: yeap, that's closer to being enough for a 13 week internship 15:55:49 I just suggested image as a start :) 15:56:24 DinaBelova: how about getting her involved in the performance profiling work? ... would she be able to get access to the Mirantis lab remotely? 15:56:44 eglynn, I'll need to discuss this, don't know right now... 15:57:03 we have kind of angry rules with access, that's why Im not actually sure 15:57:09 :) 15:57:14 DinaBelova: yeah, that's fair 15:57:29 DinaBelova, I'm 100% sure that she'll have no access for it 15:57:36 we have the answer 15:57:37 :) 15:58:01 SergeyLukjanov: fair enough 15:58:14 DinaBelova: so IMO the best type of topic for OPW is some externally recognizable feature or impact that the intern can point to later as their own 15:58:30 eglynng, a-ha, ok, will manage this 15:58:35 eglynn ^^ 15:58:44 DinaBelova: (as opposed to of a bunch of nebulous smaller changes) 15:59:03 (I'm thinking in the context of building up their opensource "footprint") 15:59:18 eglynn, yes, that's the thing I'm thinking about as well 15:59:34 k, I guess we'll have to keep thinking on this ... when does Nelly's internship officially start? 15:59:38 eglynn, yeah, I agree.. if it's possible 15:59:53 it started on tuesday :( 15:59:55 eglynn, 9th Dec :) 16:00:00 a-ha, k 16:00:14 we're working on gnocchi lab + images stuff right now 16:00:21 and I'm looking for global task 16:00:35 ok, folks please get your thinking-caps on re a new topic, as time is already a-ticking 16:00:42 #topic open discussion 16:00:46 Config db blueprint https://review.openstack.org/#/c/127086/ could use a push over the finish line. 16:00:55 FYI kilo PTL update slides here http://bit.ly/ceilometer-kilo-update 16:01:03 nealph_: cool, will look 16:01:11 outta time I'm afraid! 16:01:24 thanks folks for your time :) 16:01:27 eglynn: New bug with samples' duplicating 16:01:29 #endmeeting ceilometer