14:01:18 <isviridov> #startmeeting magnetodb
14:01:18 <openstack> Meeting started Thu Mar 12 14:01:18 2015 UTC and is due to finish in 60 minutes.  The chair is isviridov. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:22 <openstack> The meeting name has been set to 'magnetodb'
14:01:49 <isviridov> #link https://wiki.openstack.org/wiki/MagnetoDB/WeeklyMeetingAgenda#12_Mar.2C_2015.2C_14:00_UTC
14:01:52 <isviridov> Agenda
14:02:05 <isviridov> Not too many topics
14:02:46 <isviridov> Not sure I know what action items left from previous meeting
14:03:05 <isviridov> #topic Go through action items
14:03:25 <isviridov> Guys? anything from your side?
14:03:35 <charlesw> maybe a round of status
14:03:42 <dukhlov> yes
14:03:54 <charlesw> I'll go first
14:04:06 <aostapenko> Hi, guys
14:04:06 <isviridov> charlesw: please
14:04:12 <isviridov> aostapenko: hey man
14:04:47 <charlesw> Working on the health check metrics,  https://review.openstack.org/#/c/144774/7, https://review.openstack.org/#/c/159325/, https://review.openstack.org/#/c/161743/
14:05:52 <charlesw> I'm picking up this one https://review.openstack.org/#/c/144774/9 since Andrei seems tied up with something else
14:06:05 <charlesw> And I have a dependency on it
14:07:06 <charlesw> Also working with dukhlov to merge refactor notification https://review.openstack.org/#/c/143115/
14:07:38 * isviridov thinks it is a lot of items
14:08:15 <dukhlov> I picked up refactor notification.
14:09:25 <dukhlov> When I started work on it and dig deeper I faced with a few problems
14:09:50 <dukhlov> and now I'm thinking how to implement it better
14:10:41 <charlesw> dukhlov, can you explain what problems you encountered?
14:10:42 <dukhlov> but nothing serious
14:10:57 <isviridov> charlesw: +1
14:11:27 <isviridov> #topic Round of status
14:11:34 <dukhlov> should we notify requests only passed authentification?
14:14:13 <charlesw> I wouldn't think so. Unauthenticated req should also be logged so we can understand what percentage of reqs are failing because of authn issue
14:14:13 <dukhlov> if no, in this case of authorization get failed we haven't parsed request yet
14:14:13 <dukhlov> and have no information for notification
14:14:13 <charlesw> at the end, admin should be able to tell the percentage of each response status code
14:14:54 <charlesw> That's why I implemented that part
14:15:46 <dukhlov> but at authorization stage we haven't parsed request and don't know what is this request exactly
14:16:10 <dukhlov> we could sent notification like - some request was anauthorized
14:16:13 <charlesw> we know the req, so we know the API url
14:16:54 <charlesw> API url + HTTP method maps to our API one-to-one
14:17:10 <dukhlov> no, we don't know we should duplicate parsing logic and parse it to get this infrmation
14:17:56 <charlesw> No this is not duplicate parsing since the req is rejected for failing to pass authn
14:18:24 <dukhlov> ok, duplicating code I ment
14:19:03 <charlesw> well, the mapping code I added in is much simpler than WSGI mapper
14:19:04 <dukhlov> we do it only once but if all fine using one code and if something wrong - using another
14:19:35 <charlesw> we need to handle that one way or the other
14:19:57 <dukhlov> it is simple, but it is a mess
14:21:34 <charlesw> unless we have a better solution.
14:21:49 <dukhlov> exactly
14:22:03 <isviridov> I think that we have to produce event on un authorized request, because it is important information for security auditing
14:22:08 <dukhlov> so I'm thinking how to  do this better
14:22:19 <isviridov> Another question how to code it better
14:22:45 <isviridov> dukhlov: does shared code help?
14:23:00 <dukhlov> no
14:23:11 <dukhlov> mmm
14:23:13 <dukhlov> maybe
14:23:35 <dukhlov> but not in current implementation
14:23:46 <charlesw> ominakov, welcome back
14:24:03 <dukhlov> requres some more efforts for refactoring
14:25:06 <charlesw> dukhlov, we need to speed up this one. It has a business impact
14:25:23 <dukhlov> clear
14:25:53 <charlesw> maybe we can leave it for future. The functionality needs to be in first.
14:26:16 <isviridov> dukhlov: charlesw moving on?
14:28:00 <dukhlov> I am afraid that in future it will require much more efforts to refactor it and it can remain as is,  but you are right
14:28:59 <isviridov> #topic Open discussion
14:29:52 <isviridov> Do you think that scheduled regular meeting is needed?
14:30:27 <isviridov> I mean we can have it ad-hoc and announce day before when it is needed.
14:30:31 <isviridov> What do you think?
14:31:28 <charlesw> ad-hoc seems more appropriate now since much less activities hence less topics. Or switch to bi-weekly.
14:33:17 <isviridov> I also think so. Every second week looks also good for me.
14:33:22 <isviridov> dukhlov: aostapenko?
14:34:31 <dukhlov> sounds reasonable because of decreasing contribution activity
14:35:22 <isviridov> Ok, I'll update wiki, and next meeting will take place 26 of March
14:35:34 <isviridov> #action isviridov update weekly meeting schedule
14:36:37 <isviridov> Any other topics?
14:37:13 <aostapenko> isviridov: agree
14:37:33 <isviridov> aostapenko :)
14:37:47 <isviridov> aostapenko  thx for sharing your view
14:38:45 <isviridov> dukhlov charlesw aostapenko finishing the meeting
14:39:18 <charlesw> isviridov, thanks for organizing
14:39:32 <isviridov> Thank you for comming
14:39:38 <isviridov> #endmeeting