13:00:15 <isviridov> #startmeeting magnetodb
13:00:16 <openstack> Meeting started Thu Oct  9 13:00:15 2014 UTC and is due to finish in 60 minutes.  The chair is isviridov. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:21 <openstack> The meeting name has been set to 'magnetodb'
13:00:29 <isviridov> Who is here?
13:00:31 <isviridov> o/
13:00:33 <achudnovets> hello everybody
13:00:41 <isviridov> achudnovets, hello alex
13:00:53 <rushiagr> hello!
13:01:13 <rushiagr> ajaya should be around too. Wait, I'll poke him
13:01:16 <isviridov> SpyRay, hello
13:01:31 <SpyRay> Hi All!
13:01:38 <isviridov> rushiagr, great. He has several items in agenda
13:02:03 <isviridov> Hello ajayaa
13:02:20 <ajayaa> Hi isviridov.
13:02:53 <isviridov> Ok, I think we can start
13:03:05 <isviridov> Here is today agenda #link https://wiki.openstack.org/wiki/MagnetoDB/WeeklyMeetingAgenda#Agenda
13:03:25 <isviridov> The AIs from last meeting #link http://eavesdrop.openstack.org/meetings/magnetodb/2014/magnetodb.2014-10-02-13.00.html
13:03:37 <isviridov> #topic Go through action items
13:04:02 <isviridov> dukhlov ikhudoshyn review spec for https://blueprints.launchpad.net/magnetodb/+spec/monitoring-health-check
13:04:24 <isviridov> dukhlov, ikhudoshyn any success with it?
13:04:29 <ikhudoshyn> yup
13:04:51 <ikhudoshyn> in fact there was only one open question for me
13:05:05 <ikhudoshyn> response in case of unhealthy state
13:05:12 <dukhlov> yes
13:05:28 <dukhlov> now it is returned 503
13:05:31 <ikhudoshyn> i would really like errcode other than 200 in the case
13:05:31 <aostapenko> ikhudoshyn 503
13:05:41 <dukhlov> and json response
13:05:47 <ikhudoshyn> aostapenko, is it official?
13:05:48 <dukhlov> with detailes
13:06:03 <aostapenko> ikhudoshyn, yes. and text/plain body
13:06:04 <ikhudoshyn> aostapenko, great if so
13:06:18 <ikhudoshyn> no objections from my side than
13:06:35 <dukhlov> but if we decided that it is "simple" healthcheck
13:07:07 <isviridov> ikhudoshyn, dukhlov please add your 'approved' to spec, just to keep it consistent
13:07:11 <dukhlov> and we have no plans to parse json to get detailes
13:07:19 <aostapenko> there is simple healthcheck, and healthcheck that checks subsystems. see specs please
13:07:34 <ikhudoshyn> isviridov, where to?
13:07:48 <aostapenko> https://wiki.openstack.org/wiki/MagnetoDB/specs/monitoring-health-check
13:07:50 <ikhudoshyn> isviridov, i mean approve?
13:07:59 <dukhlov> maybe it is reasonable to return more detailed status via status code?
13:08:00 <isviridov> ikhudoshyn, https://wiki.openstack.org/wiki/MagnetoDB/specs/monitoring-health-check#Specification_status
13:08:40 <dukhlov> I mean define a few codes for different cases
13:08:50 <ikhudoshyn> isviridov, tnx
13:09:01 <isviridov> dukhlov, for example?
13:09:54 <ikhudoshyn> dukhlov, are we to provide automatic recovery? if no then I don't see a usecase for that
13:10:31 <aostapenko> I think 200 and 503 are enough
13:10:44 <dukhlov> that is ok, but In this case It is not clear for me why are we sending json with detailes?
13:11:28 <ikhudoshyn> aostapenko, +1
13:12:00 <aostapenko> dukhlov, plain/text. Just to provide additional info for administrator
13:12:46 <dukhlov> aostapenko: ah, ok, I fogot that it is not REST call now
13:13:13 <isviridov> Ok, let us move on
13:13:17 <isviridov> dukhlov, ok?
13:13:21 <ikhudoshyn> isviridov, +1
13:13:24 <dukhlov> ok
13:13:29 <isviridov> ikhudoshyn dukhlov review https://wiki.openstack.org/wiki/MagnetoDB/specs/rbac
13:14:09 <isviridov> Let me share my feedback also
13:14:15 <ikhudoshyn> as for that, I'd love to see full list of permissions
13:14:32 * isviridov ikhudoshyn is faster
13:14:39 <isviridov> yeap
13:14:49 <ajayaa> Apart from permission based on roles and projects(tenants) do we need anythin else?
13:15:10 <ikhudoshyn> ajayaa, I dont see any
13:15:22 <ikhudoshyn> * anything
13:15:39 <isviridov> ajayaa, could you enumerate the list of actions we are going to restrict
13:15:49 <ajayaa> Then the permission listed in the spec are enough.
13:15:52 <ajayaa> Okay.
13:16:04 <dukhlov> LGTM in general, but i have seen there some kind of definition of simple language for rights
13:16:19 <ajayaa> We can restrict all actions.
13:16:40 <ajayaa> If you want to make an api public then just don't put any rule for it policy.json file.
13:16:52 <ajayaa> I will provide an example of that in the commit log.
13:16:57 <dukhlov> role:admin and project_id:(project_id)s
13:17:09 <dukhlov> now we have "AND"
13:17:19 <dukhlov> Do we plan to have "OR"
13:17:33 <ajayaa> dukhlov, yes.
13:17:41 <ajayaa> It is already there in policy.
13:17:54 <ajayaa> The openstack common code provided already does this.
13:18:12 <isviridov> ajayaa, yes. But the actions will be coded, so having a list will help to document exact maning
13:18:30 <isviridov> *naming
13:18:37 <ajayaa> Okay. I will modify the spec to reflect the same.
13:18:54 <isviridov> Thank you
13:19:37 <dukhlov> ajayaa:  openstack common code? which library? where can I find it?
13:20:34 <ajayaa> If you see my patch there itself, magnetodb/openstack/common/policy.py
13:21:02 <ajayaa> That is the common code shared by every project which does role based policy checking.
13:21:28 <isviridov> ajayaa, another think could you please keep the template structure. I mean https://wiki.openstack.org/wiki/MagnetoDB/specs/template
13:22:15 <ajayaa> isviridov, I have missed some points in the template, I think.
13:22:26 <ajayaa> I will update the spec. :)
13:22:44 <ikhudoshyn> ajayaa, we're trying to get rid of *.openstack.common when possible
13:23:07 <dukhlov> ajayaa: cool, thank you
13:23:13 <ikhudoshyn> if u know a library where this stuff resides could u pls use it?
13:23:31 <ajayaa> ikhudoshyn, There is no library for it as of now.
13:23:41 <ikhudoshyn> ajayaa, ok ic
13:23:46 <ajayaa> In future oslo people could include it, but I am sure.
13:23:52 <achudnovets> ikhudoshyn: https://github.com/openstack/oslo-incubator/blob/master/openstack/common/policy.py
13:24:23 * isviridov came back
13:24:25 <isviridov> dukhlov, ikhudoshyn next point?
13:24:32 <dukhlov> +1
13:24:36 <ikhudoshyn> achudnovets, are we to see oslo.incubator on pypi?
13:24:47 <ikhudoshyn> achudnovets, in some future?
13:25:25 <achudnovets> It may become a library some day :)
13:25:35 <ikhudoshyn> :) tnx
13:25:41 <ikhudoshyn> ikhudoshyn, lets move on
13:25:52 <isviridov> isviridov start create spec repo like https://github.com/openstack/nova-specs
13:25:52 <ajayaa> ikhudoshyn, Before becoming library common code go thorough oslo.incubator.
13:25:57 <ikhudoshyn> s/ikhudoshyn/isviridov
13:26:26 <isviridov> It is for me. So no progress here yet
13:26:33 <ikhudoshyn> ajayaa, that makes sense, i just dont really like copypased code
13:26:36 <isviridov> But we will have it for kilo
13:27:00 <ikhudoshyn> isviridov, we're ;looking forward ))
13:27:13 <isviridov> ikhudoshyn, :)
13:27:15 <isviridov> ominakov describe security impact here https://wiki.openstack.org/wiki/MagnetoDB/specs/monitoring-api
13:27:28 <isviridov> ominakov, around?
13:28:11 <isviridov> Ok.We have other point to discuss
13:28:18 <ajayaa> ikhudoshyn, If everybody feels like we should wait for policies to become a library, then I am fine with it. :)
13:28:32 <ikhudoshyn> ajayaa, no way)
13:28:45 <achudnovets> isviridov: +1 :)
13:29:10 <isviridov> ajayaa, how long it can take?
13:29:23 <ajayaa> isviridov, I have no idea.
13:30:19 <isviridov> We had the same with notifications, I don't think that it should stop us.
13:30:51 <isviridov> Or even more, it is a greate chance to contribute to oslo
13:31:02 <ajayaa> Yes. besides every other project is reusing that piece of code.
13:31:29 <isviridov> ajayaa, yeap
13:31:49 <isviridov> Ok next big topic looks like from you
13:31:54 <isviridov> #topic Decide how to do metering. Define a clear boundary between monitoring api and Ceilometer metering through Magnetodb notifications.
13:32:13 <isviridov> #topic Decide how to do metering
13:32:35 <ajayaa> Do we have a basic idea of what to meter?
13:32:56 <ajayaa> besides byte usage and #rows in a table
13:33:08 <keith_newstadt> we have docs describing key metrics
13:33:23 <keith_newstadt> have that info been shared with the community?
13:33:36 <ajayaa> I don't see it.
13:34:12 <keith_newstadt> we should put it in the blueprint
13:34:23 <isviridov> keith_newstadt, 1 sec
13:34:52 <isviridov> Here it is #link https://docs.google.com/a/mirantis.com/spreadsheets/d/1tYvgCSvkcOVED46MX8qSlUyrhNhHlyTrVkX7AXP-XR4/edit#gid=0
13:35:18 <isviridov> Here is the list
13:35:26 <isviridov> ajayaa, does it work for you?
13:35:45 <ajayaa> yep. I can see it.
13:37:15 <isviridov> So the data with Source API==KVaaS API is expected to be collected with monitoring API
13:38:11 <ikhudoshyn> isviridov, and everything other is left for ceilometer?
13:38:40 <ajayaa> Ceilometer would only consume notifications as of now.
13:39:00 <isviridov> ajayaa, what about pooling data?
13:39:07 <ajayaa> If we are going to do metering through ceilometer then we should emit notifications containing these information.
13:39:37 <ajayaa> I talked with ceilometer devs and they are okay with notifications but not polling.
13:39:49 <isviridov> ajayaa, I mean pollster http://docs.openstack.org/developer/ceilometer/contributing/plugins.html#pollster
13:40:36 <isviridov> What the reasoning to work only with notifications?
13:41:50 <isviridov> ikhudoshyn, actually all can be sent to celiometer, the question is how and if it is needed there at all
13:42:06 <ajayaa> isviridov, no dependency on code of other modules.
13:42:31 <ajayaa> services*
13:42:43 <isviridov> ajayaa, got you
13:43:17 <isviridov> ajayaa, yeap it is a big question for us as non integrated project. We have to figure out how we can go here
13:43:51 <isviridov> Ok, let us summarize
13:43:54 <ajayaa> We could have some code running periodically which would send notifications.
13:44:24 <isviridov> #info celiometer team prefers notifications
13:45:31 <isviridov> ajayaa, are you ok with a list of metrics or have ideas what we can add?
13:45:58 <ajayaa> isviridov, I will go through the list in detail and let you know.
13:46:22 <isviridov> #action ajayaa review current list of metrics
13:46:28 <isviridov> Anything else>
13:46:29 <isviridov> ?
13:46:42 <ikhudoshyn> isviridov, move on?
13:46:48 <isviridov> ajayaa, keith_newstadt move on?
13:46:57 <ajayaa> okay.
13:47:08 <isviridov> #topic UUID for a table
13:47:43 <ajayaa> The need for this right now is in ceilometer which needs a field resource_id.
13:47:59 <isviridov> ajayaa, I believe celiometer is a big topic, let us continue offline. But very appreciate your work!
13:48:03 <ajayaa> which should be unique per resouce which is being measured.
13:48:27 <ajayaa> okay.
13:49:09 <ajayaa> Also UUID would help in making our apis more openstack way.
13:49:13 <isviridov> I personally would like to see UUID for table
13:49:32 <isviridov> dukhlov, ikhudoshyn, charlesw any thoughts?
13:49:34 <ajayaa> isviridov, yes.
13:49:37 <ajayaa> +1
13:49:58 <ikhudoshyn> isviridov, where exactly u want to see them?
13:50:12 <isviridov> As table attribute
13:50:26 <ikhudoshyn> is it only about haivng them in table_info or u expect to expose it?
13:50:38 <ikhudoshyn> like in resource url?
13:50:55 <ajayaa> ikhudoshyn, unless exposed what value would it add?
13:51:29 <ikhudoshyn> ajayaa, that's what I tey to figure out)
13:51:51 <charlesw> table name + project id is already unique. What's the purpose for uuid for table?
13:52:08 <ikhudoshyn> charlesw, +1
13:52:17 <keith_newstadt> charlesw +1
13:52:18 <aostapenko> charlesw, table can be recreated
13:52:29 <ajayaa> aostapenko +1
13:52:34 <aostapenko> and it will be another resource
13:52:40 <ajayaa> I was waiting for you to tell this. :)
13:53:00 <keith_newstadt> how would the user use the uuid?
13:53:11 <dukhlov> table name + project id is already unique in scope of magnetodb
13:53:43 <keith_newstadt> i'm trying to understand the use case we'd be solving for
13:53:47 <aostapenko> dukhlov, but not in scope of OpenStack. If we consider a table as a resource
13:54:05 <dukhlov> sould this ID be unique resoure for monitoring in scope of all ceilometer resoures being monitored
13:54:06 <dukhlov> ?
13:54:56 <ajayaa> dukhlov, yes. At least for one service.
13:57:54 <aostapenko> It's not a problem to add uuid just for ceilometer. but it will be openstack style if we expose it
13:58:32 <isviridov> HEAT has similar story. Implementing AWS CloudFormation API they have as stack name as identifier, but added UUID as well
13:58:34 <isviridov> http://developer.openstack.org/api-ref-orchestration-v1.html
13:59:10 <isviridov> It looks like we don't have an agreement here. Let us return back to it offline or in ML
13:59:17 <ikhudoshyn> so for ceilometer we could have table name + uuid as a resource id
13:59:20 <charlesw> Then we need to change MDB resource url to use uuid instead of table name. Different than Dynamo
13:59:51 <ikhudoshyn> charlesw, OS REST API already differs from Dynamo one
14:00:06 <ikhudoshyn> but this is a topic to discuss anyway
14:00:25 <isviridov> We are run out of time
14:00:40 <isviridov> #topic Juno delivery status overview
14:01:03 <isviridov> The current rc1 is the last version before juno release
14:01:51 <isviridov> I've created kilo and we can start with suggesting BPs there https://launchpad.net/magnetodb/kilo
14:02:15 <isviridov> Thank you for attending the meeting.
14:02:20 <isviridov> #stopmeeting
14:02:31 <rushiagr> thanks all
14:02:35 <rushiagr> isviridov: endmeeting :)
14:02:41 <isviridov> #endmeeting