14:00:19 <isviridov> #startmeeting magnetodb
14:00:20 <openstack> Meeting started Thu Dec 11 14:00:19 2014 UTC and is due to finish in 60 minutes.  The chair is isviridov. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:24 <openstack> The meeting name has been set to 'magnetodb'
14:00:35 <isviridov> Who is with us today?
14:00:54 <isviridov> Hello nunosantos
14:00:58 <ominakov> hi, guys
14:00:59 <nunosantos> hello
14:01:08 <dukhlov> hello
14:01:09 <achuprin_> o/
14:01:11 <aostapenko> hi
14:01:25 <isviridov> What is the weather in Boston now?
14:01:35 <isviridov> nunosantos any snow?
14:01:36 <ygbo> Thanks isviridov
14:02:00 <ikhudoshyn> 0/
14:02:08 <isviridov> \0
14:02:34 <isviridov> Ok, let start
14:02:47 <ajaya> o/
14:02:52 <nunosantos> no major snow yet. cold though
14:02:59 <isviridov> The agenda for today https://wiki.openstack.org/wiki/MagnetoDB/WeeklyMeetingAgenda#Agenda
14:03:36 <isviridov> nunosantos there was a lot of snow here, but now mostly all melt
14:03:46 <isviridov> #topic Go through action items isviridov
14:04:07 <isviridov> Seems there are no action items from last time
14:04:15 <isviridov> http://eavesdrop.openstack.org/meetings/magnetodb/2014/magnetodb.2014-12-04-14.00.html
14:04:53 <isviridov> I believe we have what to discuss in Open discussions part
14:05:07 <isviridov> #Open discussion isviridov
14:05:24 <achudnovets> o/
14:05:27 <isviridov> achudnovets would you like to start?
14:05:44 * isviridov doesn't see charlesw
14:06:25 <achudnovets> ok
14:06:34 <openstackgerrit> Andrei V. Ostapenko proposed stackforge/magnetodb: Adds table_id field to table description  https://review.openstack.org/140740
14:07:05 <achudnovets> we have an idea to change monitoring API url
14:07:38 <achudnovets> and use something like this /v1/admin/monitoring/tables?tenant_id=bla-bla
14:07:51 <charlesw> do you have any doc?
14:07:52 <isviridov> charlesw hey, we are discussing exposing the statistics per table, but in comfortable way for statsd
14:07:58 <achudnovets> not yet
14:08:15 <achudnovets> it's just an idea now
14:08:36 <isviridov> charlesw there is no doc yet, but there is a problem we would like to hear your oppinion about
14:08:52 <achudnovets> response will contain uuid, table name, tenant id and table stats
14:09:33 <achudnovets> response can be filtered by tenant, table id, table name etc
14:09:58 <achudnovets> big question is auth for this api
14:10:16 <achudnovets> personally I would prefer to use keystone auth
14:10:18 <dukhlov> achudnovets, what does admin mean in /v1/admin/monitoring/tables?tenant_id=bla-bla?
14:10:41 <achudnovets> admin is just part of url
14:10:45 <achudnovets> like 'data'
14:11:11 <charlesw> I have same question. Why url is not hierarchical?
14:11:11 <dukhlov> but we have data, management monitoring
14:11:21 <dukhlov> it is type of aplication
14:11:21 <ikhudoshyn> +1 to Dima
14:11:41 <dukhlov> admin is something new to me
14:12:12 <achudnovets> we can stick all non-data url under 'admin' url part. Or we can live it as it is
14:12:40 <dukhlov> yes we can but why?
14:12:51 <achudnovets> main idea is to use single url for all monitoring tasks
14:12:51 <isviridov> Before we proced with url, let us define the problem.
14:13:01 <dukhlov> do we have some reason for that?
14:13:11 <ikhudoshyn> achudnovets: why not just /v1/monitoring/...?
14:13:11 <isviridov> dukhlov let me clarify
14:13:39 <isviridov> ikhudoshyn current Monitoring API is designed for user, and really difficult to  use by monitoring tools like collectd, nagios so on. Mostly because of dependency to to keystone and necessity to manage credentials. So, the idea is to introduce an api for collecting this data under the cloud
14:13:42 <achudnovets> ikhudoshyn: it's ok for me
14:14:38 <ikhudoshyn> isviridov: ic
14:14:55 <achudnovets> isviridov: I would like to say the main problem is that client needs to know all tenants to be able to monitor them
14:15:18 <isviridov> ikhudoshyn for /v1/monitoring we still have to manage authorization and don't have a tenant_list feature, to see statistics over all mdb
14:15:24 <dukhlov> isviridov, it is authentification staff and should be configurable
14:15:31 <isviridov> achudnovets just mentioned, thank you
14:16:00 <isviridov> dukhlov ikhudoshyn charlesw let us move back to problem
14:16:02 <ikhudoshyn> isviridov: than it looks like a completely separate app
14:16:20 <ikhudoshyn> with a separate endpoint, not just url
14:16:26 <isviridov> The suggested solution is one more api, anu other ideas?
14:16:39 <ikhudoshyn> +1 for another api
14:16:47 <achudnovets> -1
14:16:52 <dukhlov> -1
14:17:13 <dukhlov> again, what is the problem?
14:17:18 <isviridov> achudnovets dukhlov ideas?
14:17:50 <achudnovets> I think it can be just part of existing API but it should be accessible only by users with admin role
14:18:03 <isviridov> dukhlov again, current Monitoring API is designed for user, and really difficult to  use by monitoring tools like collectd, nagios so on. Mostly because of dependency to to keystone and necessity to manage credentials and no ability to have a tenant list.\
14:18:14 <ikhudoshyn> dukhlov: seems like the problem is we need <tenant_id> to make /v1/monitoring/<tenant_id>/ url
14:18:31 <isviridov> ikhudoshyn exactly
14:18:46 <dukhlov> ok, so 2 problems - authentification and how to get tenant list
14:18:49 <dukhlov> right?
14:19:09 <isviridov> achudnovets it means we need to have keystone call before calling mdb. F.e. in nagios
14:19:19 <achudnovets> so my idea is /v1/monitoring/tables with filters. Only admin can use it. 403 in all other cases
14:19:26 <charlesw> dukhlov, +1
14:19:36 <isviridov> dukhlov let us start from these two
14:19:41 <achudnovets> isviridov: yes
14:19:57 <ikhudoshyn> achudnovets: how do you know he is an admin?
14:19:58 <dukhlov> authentification should be configurable, we can switch off it if it is needed
14:20:24 <isviridov> dukhlov right, but to switch off/on we need it separate first
14:20:31 <achudnovets> isviridov: admin role in "magnetodb" tenant
14:20:45 <achudnovets> polisy.json
14:21:01 <ikhudoshyn> achudnovets: i.e. we still need request to keystone first?
14:21:03 <achudnovets> * policy.json
14:21:11 <dukhlov> about tenant list... we need provide path to monitored resourse
14:21:13 <achudnovets> ikhudoshyn: yes
14:21:15 <dukhlov> and that is all
14:21:34 <isviridov> achudnovets anyhow it involves keystone, it is the same we have now. You can call keystone for tenant list and call mdb n-times for data.
14:21:44 <ikhudoshyn> dukhlov: the idea is to grab all stats in a single request
14:22:17 <isviridov> ikhudoshyn it is more optimization, but with specific api we can do a lot of optimizations
14:22:18 <dukhlov> ok let /v1/monitoring will return all tennants metrics
14:22:57 <achudnovets> isviridov: partially agree. You'll need very simple keystone config for /v1/monitoring/tables valiant
14:23:04 <achudnovets> *variant
14:24:20 <isviridov> dukhlov what about authorization if so?
14:24:47 <isviridov> miqui_ welcome to meeting
14:24:49 <ikhudoshyn> achudnovets: did i get it right, now we have a long and complex way to do it, and separate api will give us another one, fast and convenient?
14:25:44 <miqui_> hi isviridov...
14:26:20 <achudnovets> ikhudoshyn: what do you mean "separate api"? new service?
14:26:33 <ikhudoshyn> yep
14:26:33 <isviridov> ikhudoshyn yes, or better to say reasonable for monitoring purposes
14:26:38 <dukhlov> test
14:26:43 <ikhudoshyn> dukhlov: passed
14:26:44 <isviridov> dukhlov test
14:26:46 <achudnovets> dukhlov: pong )
14:26:47 <charlesw> Is it based on the idea we discussed last week, using domain admin role?
14:28:33 <achudnovets> charlesw: yep, it's about monitoring api.
14:29:20 <dukhlov> test2
14:29:27 <ikhudoshyn> dukhlov: passed2
14:30:21 <dukhlov> "/v1/monitoring/tenants/tenant_id" for specific tenant
14:30:39 * isviridov what a nice formatting
14:31:03 <dukhlov> "/v1/monitoring/tenants/tenant_id/tables/table_name" for specific table
14:31:42 <ikhudoshyn> dukhlov: too long
14:31:49 <achudnovets> ikhudoshyn: +1
14:32:46 <dukhlov> we can deploy two different pipelines for different urls but use the same application
14:33:06 <dukhlov> too long but it is path to resource to be monitored
14:33:09 <ikhudoshyn> dukhlov: -1 for the same app
14:33:13 <nunosantos> maybe remove the “tables” part, just tadd the table name adter tenant_id
14:33:22 <nunosantos> * add
14:33:42 <achudnovets> dukhlov: I think we can use single url for monitoring.
14:34:31 <charlesw> nunosantos, -1, not by openstack convention
14:34:52 <achudnovets> url like /v1/monitoring/ or /v1/monitoring/tables
14:35:25 <charlesw> why not /v1/monitoring/tenants?
14:35:46 <miqui_> what about keeping url simple and passing additional params in the http headers?
14:35:46 <achudnovets> because it's not info about tenants
14:35:49 <isviridov> dukhlov I don't like the way of mixing existing functionality and hacking with deployment.
14:35:55 <miqui_> or part of a json payload?
14:36:22 <achudnovets> miqui_: it will be GET request with params
14:36:33 <miqui_> k..
14:38:41 <achudnovets> if we'll have monitoring with data API I'd like to use keystone auth for it. If it will be separate app, then we can use any type of auth
14:38:59 <ikhudoshyn> achudnovets: +1
14:40:16 <ajaya> +1 for a different app. Ideally we should not mix user apis with management apis.
14:40:24 * isviridov do we have any other topics to discuss/
14:40:41 <ominakov> achudnovets, what do you mean in "monitoring with data API" ?
14:41:17 <achudnovets> ominakov: just like current implementation
14:42:37 <ajaya> isviridov, I have a question regarding incubation of mdb? Are we planning to apply for incubation? If yes, when? What benefit do we get by becoming an incubated project?
14:43:20 <miqui_> if the big picture goal it to become an openstack core project.. then this is a big first step..
14:43:26 <charlesw> achudnovets, what do you mean by any type of auth? Do you mean we need to come up with a separate authN other than keystone?
14:44:50 <isviridov> ajaya yes we are planning to do it, I really hoped to do it last cycle, so the plan is this cycle.
14:45:02 <achudnovets> charlesw: yes. I think ikhudoshyn and isviridov means that we can use non-keystone auth for monitoring. Is it right?
14:45:53 <ikhudoshyn> achudnovets: possibly
14:46:02 <isviridov> ajaya the main benefit is some king of endorsement of project
14:46:26 <ajaya> isviridov, so if all goes well then mdb would be an incubated project by end of kilo?
14:48:15 <isviridov> ajaya we will see, the incubation process and status is changing now, but teh goal is to reach this status whatever it is.
14:48:26 <isviridov> ajaya more details http://lists.openstack.org/pipermail/openstack-tc/2014-November/000887.html
14:48:39 <charlesw> isviridov, let us know what we all can do to get there
14:49:24 <isviridov> charlesw sure
14:49:49 <isviridov> Where are we with monitoring?
14:50:03 <isviridov> achudnovets could you summarize?
14:50:17 <achudnovets> ok
14:50:56 <miqui_> +1 on incubation, am late in the game..but i'll do what i can...
14:52:03 <isviridov> miqui_ great to see you with us.  What company are you working on?
14:52:51 <miqui_> i work for Hewlett-Packard
14:53:48 <isviridov> Cool, it helps with diversity of team, what is one of requerements. Waiting for your patches :)
14:54:28 <achudnovets> so the idea is to change monitoring API url and create separate app for it. or we can change our existing controllers for monitoring api. I can prepare spec for it and then we can discuss it in gerrit
14:55:07 <charlesw> miqui, what location? I'm with Symantec, Boston
14:55:11 <openstackgerrit> Andrei V. Ostapenko proposed stackforge/magnetodb: Adds table_id field to table description  https://review.openstack.org/140740
14:55:27 <isviridov> #action achudnovets create a spec for integration with external monitoring systems
14:55:30 <miqui_> charlesw: Atlanta
14:55:41 * isviridov charlesw and miqui_ are going to have some beer
14:55:47 * isviridov seems not
14:56:49 * isviridov 4 mins left
14:58:12 <isviridov> Countdown
14:58:20 <isviridov> 3
14:58:24 <isviridov> 2
14:58:28 <isviridov> 1
14:58:57 <isviridov> Thank you fro comming, see you in IRC and ML
14:59:10 <isviridov> #endmeeting