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 rem ove 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