18:00:55 <SlickNik> #startmeeting trove
18:00:56 <openstack> Meeting started Wed May 28 18:00:55 2014 UTC and is due to finish in 60 minutes.  The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:00 <openstack> The meeting name has been set to 'trove'
18:01:21 <SlickNik> Giving folks a couple of minutes to trickle in
18:01:27 <robertmyers> o/
18:01:28 <denis_makogon> o/
18:01:40 <SlickNik> Agenda at:
18:01:41 <iccha1> o/
18:01:42 <SlickNik> #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting
18:01:45 <annashen_> o/
18:01:45 <cweid> wassup yall
18:01:47 <pdmars> o/
18:01:53 <mattgriffin> o/
18:01:54 <denis_makogon> cweid, 'sup man
18:01:55 <grapex> o/
18:01:59 <kevinconway> o/
18:02:00 <imsplitbit> o/
18:02:00 <cweid> ello
18:02:11 <tvoran> o/
18:02:21 <hub_cap> ohai
18:02:39 <cp16net> present
18:02:42 <SlickNik> #link http://eavesdrop.openstack.org/meetings/trove/2014/trove.2014-05-21-18.01.html
18:03:08 <glucas> o/
18:03:23 <imsplitbit> Can we talk about my merge request :P
18:03:23 <k-pom> o/
18:03:25 <imsplitbit> lol
18:03:28 <imsplitbit> kidding kidding
18:03:35 <peterstac> o/
18:03:53 <SlickNik> Okay, let's get started.
18:04:02 <dougshelley66> o/
18:04:03 <SlickNik> #topic Refactor/Re-write notifications
18:04:10 <esmute> o/
18:04:11 <denis_makogon> #link http://osdir.com/ml/openstack-dev/2014-05/msg01619.html
18:04:12 <hub_cap> imsplitbit: can we talk about SHADDUP
18:04:40 <denis_makogon> i've wrote a ML about that but didn't receive any response from -cores
18:05:13 <SlickNik> denis_makogon: I think what the issues are aren't clearly defined.
18:05:18 <denis_makogon> i'm interesting in re-defining notifications contract, because there're concerns about that
18:05:49 <denis_makogon> SlickNik, issue is the actual payload of each notifications
18:05:53 <hub_cap> denis_makogon: plz link from lists.openstack in teh future. someon said they heard an advertisement on osdir
18:05:56 <hub_cap> #link http://lists.openstack.org/pipermail/openstack-dev/2014-May/035740.html
18:06:13 <denis_makogon> hub_cap, thanks
18:06:17 <hub_cap> npnp
18:06:20 <cp16net> SlickNik: did we want to go over the action items or not doing that any more?
18:07:12 <SlickNik> cp16net: That was my fail; I didn't notice we had one. Let's  go over that after this discussion.
18:07:19 <cp16net> k
18:07:28 <denis_makogon> i'd like to fix given issues( in ML) to make notification flexible and not pinned to any OS service at all
18:07:42 <denis_makogon> since it's now hardly pinned to Nova service
18:08:06 <robertmyers> well, these notifications are used for billing
18:08:11 <grapex> denis_makogon: I disagree that it isn't flexible
18:08:16 <denis_makogon> example : AZ for each payload seems to be redundant
18:08:17 <robertmyers> so they are tied to resources
18:08:40 <grapex> Like I don't get what use case people might have they can't accomplish due to how notifications work today
18:08:58 <denis_makogon> grapex, at least move AZ to create call and pass it as one of parameters(**kwargs)
18:09:01 <grapex> And I know that both Rax and HP people are using the notifications as they exist today
18:09:10 <kevinconway> regardless of what client/mechanism you use to get the values. you cannot remove values from the existing events
18:09:11 <juice> indeed
18:09:28 <SlickNik> Yes, these events are primarily for billing.
18:09:32 <denis_makogon> when we would move to heat - it would be impossible to use novaclient inside notifications
18:09:39 <vipul> denis_makogon: the reason why it's in every message is because it allows us to miss any given message without missing any info
18:09:56 <denis_makogon> vipul, can we make payload more generic
18:09:59 <denis_makogon> ?
18:10:14 <robertmyers> it is generic
18:10:17 <vipul> denis_makogon: it is generic, in that you can add additional things
18:10:32 <robertmyers> we can add but not remove
18:10:39 <denis_makogon> i wrote small spec for new types of notification payloads
18:10:41 <grapex> denis_makogon: I don't understand though why removing something from it will increase flexibility
18:10:42 <denis_makogon> #link https://wiki.openstack.org/wiki/Trove/trove-notifications-v2
18:10:50 <grapex> If you don't want to use the AZ, you can ignore it.
18:11:12 <denis_makogon> grapex, no, take a look at current implementation
18:11:23 <vipul> denis_makogon: what is the motivation for this?  is there a hole somewhere in teh current format?
18:11:39 <grapex> denis_makogon: I am - I'm looking at line 97 of trove/taskmanager/models.py
18:11:50 <denis_makogon> vipul, when i use heat - i cannot use nova for retrieving AZ
18:12:06 <robertmyers> denis_makogon: why not?
18:12:08 <hub_cap> will the AZ not come back denis_makogon ?
18:12:11 <vipul> heat doesn't tell you AZ? is that the issue?
18:12:16 <hub_cap> right ^^
18:12:22 <hub_cap> if heat has no AZ we should add it in
18:12:41 <denis_makogon> heat can tell, be each time notification is called - method calls nova for AZ
18:12:48 <denis_makogon> https://github.com/openstack/trove/blob/master/trove/taskmanager/models.py#L89-L98
18:12:53 <denis_makogon> #link https://github.com/openstack/trove/blob/master/trove/taskmanager/models.py#L89-L98
18:13:08 <hub_cap> sure you can do a "if heat: use_heat_to_get_az"
18:13:14 <hub_cap> so just add an if stmtm
18:13:24 <robertmyers> denis_makogon: pass a server kwarg
18:13:25 <vipul> denis_makogon: so you're concerned about the # of times we invoke the nova API?
18:13:26 <robertmyers> done
18:13:43 <denis_makogon> vipul, yes
18:13:46 <SlickNik> robertmyers: yeah that sounds like a bug too, not a bp.
18:14:02 <grapex> Also- is there going to be some rule that the moment we provision with Heat, we can never talk to the Nova API again?
18:14:09 <denis_makogon> robertmyers, server term is specific only for nova, and not for Heat
18:14:18 <grapex> It seems a little overzealous
18:14:23 <robertmyers> SlickNik: yeah, a little refactor not a huge change
18:14:29 <SlickNik> grapex: not that I'm aware of.
18:14:32 <robertmyers> denis_makogon: so
18:14:33 <kevinconway> i dont see why the novaclient wont work. heat has to create nova resources correct?
18:14:35 <denis_makogon> grapex, for now - no, but soon we will
18:14:38 <vipul> denis_makogon:  I don't think we need to worry about that.. at least not now.. the exists events are meant to be called every 30 mins or so..
18:15:10 <denis_makogon> vipul, can we move out nova API call send_event ?
18:15:42 <denis_makogon> also, therea are problems with payload attributes
18:15:56 <denis_makogon> like instance_type  - is a actual flavor
18:15:59 <kevinconway> denis_makogon: what is the plan to provide the information that was provided by the nova call without the client?
18:16:21 <vipul> denis_makogon: i am not sure i understand what you want to move out.. I don't mind calling nova a hundred times .. if that's what it takes to get the info
18:16:34 <juice> denis_makagon: let's be clear here...there are existing billing departments that use this structure and format today to bill clients
18:16:48 <hub_cap> ++
18:16:54 <juice> do you want us to go back to the billing department and change the process
18:17:06 <denis_makogon> so, we still should stick with current contract ?
18:17:10 <juice> if so there better be a very very good reason
18:17:17 <juice> I don't see why not
18:17:29 <vipul> feel free to add any additional fields you want
18:17:32 <SnowDust> :)
18:17:35 <juice> I don't think this is an issue that we should spend resources on
18:17:37 <cp16net> #agreed we should keep the contract
18:17:37 <denis_makogon> juice, i want to change notification payloads to be more meaningful and correct
18:17:40 <hub_cap> denis_makogon: if you are using heat, you can use heatclient to populate that
18:17:44 <robertmyers> denis_makogon: there is not need to change the contract just fix the bug I mentioned
18:17:45 <hub_cap> rather than novalcient
18:17:58 <hub_cap> at the end of the day, it needs the values in the json, its a contract
18:18:24 <denis_makogon> how to deal with incorrect terms inside payload ?
18:18:30 <denis_makogon> like a mentioned
18:18:35 <robertmyers> can't change them
18:18:38 <denis_makogon> instance_type - is a flavor name
18:18:43 <robertmyers> they are set
18:19:02 <iccha1> denis_makogon: u can add additional fields and ur billing can choose what to read
18:19:12 <juice> denis_makagon: easy it's a wart or something that might not make sense to you but think of the amount of work this will cause
18:19:13 <denis_makogon> so, can i refactor notification and keep contract as is ?
18:19:14 * imsplitbit smells a dead horse
18:19:20 <SlickNik> Okay, I think we've spent 15 minutes on this
18:19:25 <juice> you can always add your own wrapper to correct the terms
18:19:25 <SlickNik> And we need to move on.
18:19:27 <kevinconway> v2 will fix all these problems
18:19:37 <vipul> is there versioning for notifications?
18:19:41 <juice> kevinconway: actually v2.1
18:19:48 <denis_makogon> vipul, no
18:20:04 <vipul> that seems like a big hole then
18:20:25 <hub_cap> kevinconway: i like the way you think!
18:20:34 * hub_cap regrets saying that
18:20:45 <denis_makogon> so, can i refactor notification without changing contract?
18:20:51 <SlickNik> I don't think we should change the current fields since billing is relying on them.
18:20:51 <kevinconway> vipul: seems like we can break all the contracts when we rev Trove. in the mean time denis_makogon can only add, not remove
18:21:01 <robertmyers> denis_makogon: why refactor?
18:21:11 <denis_makogon> to avoid using novaclient directly and pick AZ from kwargs ?
18:21:23 <robertmyers> you can do that now
18:21:29 <robertmyers> just pass server
18:21:46 <robertmyers> it is already setup to do that
18:21:58 <denis_makogon> robertmyers, but it requires nova format for attributes
18:22:07 <robertmyers> so mimic it
18:22:23 <SlickNik> denis_makogon: No, it doesn't need a refactor as discussed.
18:22:26 <denis_makogon> why not just take it like : kwargs.get("az")
18:22:54 <SlickNik> #topic Action Items
18:22:55 <robertmyers> cause change is bad
18:22:57 <denis_makogon> it would not work with heat since we need to do +1 API call
18:23:08 <SlickNik> cp16net: You had something here
18:23:12 * hub_cap channels cartman "with athoritahhhhhh"
18:23:23 <grapex> I propose we start having a new weekly meeting in #openstack-deadhorse
18:23:28 <cp16net> #link https://bugs.launchpad.net/trove/+bug/1324206
18:23:42 <cp16net> added the audit log levels bug
18:24:07 <cp16net> we should link reviews to this bug
18:24:30 <dougshelley66> how will modules be assigned?
18:24:56 <cp16net> we can break it up in the description
18:25:18 <peterstac> were you thinking of having a review per module?
18:25:34 <hub_cap> my action item proposal is dance party
18:25:37 <cp16net> yeah thats what i was thinking
18:25:41 <denis_makogon> would it be better to do sub-package per review ?
18:25:43 <hub_cap> see cp16net agrees
18:25:48 * cp16net finds a disco ball for hub_cap
18:26:36 <cp16net> denis_makogon: i'm thinking module==taskmanger or instances
18:26:40 <grapex> cp16net: Sorry about my deadhorse comment, my client fell behind.
18:26:40 <cp16net> and so on
18:26:55 <denis_makogon> cp16net, yeah, same as i said, sub-package
18:27:18 <dougshelley66> cp16net: are you saying we assign the modules in the bug description?
18:27:28 <cp16net> yeah i'll break them up
18:27:43 <cp16net> and you can sign up for them
18:27:48 <dougshelley66> ok sounds good
18:27:52 <SlickNik> cp16net: That would be helpful, thanks!
18:28:05 <cp16net> btw does everyone have access to edit the description or is it only the owner?
18:28:28 <SlickNik> cp16net: I would suggest putting it in an etherpad and linking to it from the bug description.
18:28:39 <SlickNik> I think it's the owner + bug triage team
18:28:53 <cp16net> SlickNik: yeah ok i think that makes sense
18:29:35 <SlickNik> Cool, thanks for looking into this cp16net.
18:29:42 <SlickNik> Anything else you want to add?
18:29:44 <cp16net> #action cp16net make etherpad for breaking up the modules for log auditing bug
18:29:59 <cp16net> i dont have any more unless q's
18:30:36 <SlickNik> #topic Open Discussion
18:31:27 <SlickNik> Anything?
18:31:47 <SlickNik> If not I have a short follow up with code-reviews discussion.
18:32:18 <denis_makogon> sounds great
18:33:19 <SlickNik> #link http://lihk.in/trove/reviews.htm
18:33:23 <SlickNik> #link http://lihk.in/trove/topics.htm
18:33:34 <SlickNik> #link http://lihk.in/trove/external.htm
18:33:54 <juice> those don't work
18:34:10 <SlickNik> juice, you need to be signed in to gerrit
18:34:10 <denis_makogon> juice, log in
18:34:10 <juice> I'm getting errors
18:34:12 <iccha1> juice: u need to be logged in
18:34:20 <juice> wow - say what?
18:34:26 <SlickNik> So these are generated programatticall
18:34:30 <SlickNik> y
18:34:30 <cweid> juice you need to be logged in
18:34:30 <kevinconway> i don't like any of these
18:34:33 <kevinconway> can you change them all?
18:34:39 <SlickNik> From https://github.com/SlickNik/trove-reviews
18:34:44 <juice> oh thanks cweid - glad someone is watching out for me
18:34:45 <imsplitbit> :(
18:34:53 <iccha1> SlickNik: so the topics, why are there only limited number of topics there
18:34:56 <SlickNik> kevinconway: you can add a dash you like
18:34:57 <hub_cap> juice: did u sign in? ;)
18:35:00 <cp16net> juice: you should be logged in :-P
18:35:14 <SlickNik> iccha1: It's based off of https://github.com/SlickNik/trove-reviews/blob/master/topics.yaml
18:35:23 <juice> oh wow...is this what they call gerrit?
18:35:37 <grapex> SlickNik: These are awesome!
18:35:44 <imsplitbit> )))
18:35:54 <juice> SlickNik!! SlickNik!!
18:36:08 <SlickNik> I think he finally managed to sign in :P
18:36:19 <denis_makogon> SlickNik, last one missing heat deps
18:36:28 <juice> no I am looking over esmute's shoulder
18:36:33 <cp16net> SlickNik: the yaml is pretty
18:36:40 <cp16net> for the url
18:37:03 <iccha1> sweet this looks really good SlickNik
18:37:08 <denis_makogon> #link https://blueprints.launchpad.net/heat/+spec/update-cinder-volume
18:37:12 <grapex> SlickNik: I wonder if we could write some automation to pull in blueprints and write the topics.yaml for us
18:37:15 <denis_makogon> #link https://blueprints.launchpad.net/heat/+spec/update-cinder-volume
18:37:27 <iccha1> grapex: +1
18:37:36 <SlickNik> grapex: will look into doing that.
18:37:57 <SlickNik> btw, the dashboards get auto-published on a commit hook by https://rdjenkins.dyndns.org/job/Trove-Reviews/
18:38:17 <esmute> SlickNik: Can we make changes to the yaml? or just core can do that?
18:38:44 <SlickNik> esmute: right now it's by pull request. I'll set up a group or something to make it easier.
18:38:44 <grapex> SlickNik: Well this is pretty cool. Pretty much exactly what I wanted.
18:38:45 <esmute> to add topics and whatnot
18:38:48 <cweid> woah dyndns flashback
18:38:50 <grapex> SlickNik: Great job
18:39:15 <SlickNik> Hopefully address some of imsplitbit's concern of not showing up in the main review page as well.
18:39:18 <esmute> very nice indeed. Good job SlickNik!
18:39:42 <SlickNik> Thanks guys!
18:39:50 <dougshelley66> thanks SlickNik
18:40:00 <SlickNik> okay, denis_makogon did you have something on cinder volumes?
18:40:13 <cp16net> cool thanks for trying to make things better slick
18:40:18 <denis_makogon> SlickNik, what do you mean?
18:40:47 <vgnbkr> One thought - how about moving the last 4 columns to be the first 4 - that way you don't have to scan so far across to match things up?
18:40:59 <denis_makogon> i said that external dashboard missing another two heat deps
18:41:08 <kevinconway> and change all the colors
18:41:37 <esp> SlickNik: we need a mobile app
18:41:56 <kevinconway> it needs to use bootstrap so it's responsive
18:42:33 <SlickNik> vgnbkr: I'm not sure that's possible. I can look into it more though.
18:42:49 <SlickNik> denis_makogon: oh, that's because there's no mention of trove in either of those commit messages.
18:42:59 <peterstac> vgnbkr: maybe not the first 4, but after owner ?
18:43:05 <denis_makogon> SlickNik, yes, should they?
18:43:12 <vgnbkr> SlickNik: Thanks - only if you think it will help you, too :)
18:43:37 <SlickNik> Okay, that's all I had for now.
18:43:57 <SlickNik> #endmeeting