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