Thursday, 2014-10-09

*** vnaboychenko has quit IRC00:22
*** openstackstatus has quit IRC00:23
*** openstackstatus has joined #magnetodb00:23
*** ChanServ sets mode: +v openstackstatus00:23
*** vnaboychenko has joined #magnetodb01:05
*** charlesw has joined #magnetodb02:40
*** openstackgerrit has quit IRC02:45
*** vnaboychenko has quit IRC02:54
*** rushiagr_away is now known as rushiagr03:12
*** jeromatron has joined #magnetodb03:29
*** vivekd has joined #magnetodb03:33
*** jeromatron has quit IRC03:33
*** charlesw has quit IRC03:35
*** rushiagr is now known as rushiagr_away04:08
*** rushiagr_away is now known as rushiagr04:37
*** jeromatron has joined #magnetodb04:41
*** jeromatron has quit IRC04:44
*** jeromatron has joined #magnetodb04:48
*** jeromatron has quit IRC04:54
*** jeromatron has joined #magnetodb04:54
*** jeromatron has quit IRC05:08
*** jeromatron has joined #magnetodb05:08
*** jeromatron has quit IRC05:11
*** jeromatron has joined #magnetodb05:14
*** ajayaa has joined #magnetodb05:17
*** jeromatron has quit IRC05:17
*** jeromatron has joined #magnetodb05:23
*** jeromatron has quit IRC05:31
*** jeromatron has joined #magnetodb05:54
*** jeromatron has quit IRC05:59
*** jeromatron has joined #magnetodb06:00
*** jeromatron has quit IRC06:05
*** jeromatron has joined #magnetodb06:14
*** k4n0 has joined #magnetodb06:56
*** romainh has joined #magnetodb07:02
*** k4n0 has quit IRC07:02
*** k4n0 has joined #magnetodb07:14
*** k4n0 has quit IRC07:42
*** k4n0 has joined #magnetodb07:54
*** jeromatron has quit IRC10:05
*** tnurlygayanov has joined #magnetodb10:14
ikhudoshyno/10:23
*** ajayaa has quit IRC11:38
*** ajayaa has joined #magnetodb11:52
*** ajayaa has quit IRC12:08
*** rushiagr is now known as rushiagr_away12:20
*** openstackgerrit has joined #magnetodb12:24
isviridov0/12:25
openstackgerritIllia Khudoshyn proposed a change to stackforge/magnetodb: Use oslo.notify for notifications  https://review.openstack.org/12648912:46
isviridovHello everybody12:47
isviridovAnything to add to meeting agenda #link https://wiki.openstack.org/wiki/MagnetoDB/WeeklyMeetingAgenda#Oct_9.2C_2014.2C_13:00_UTC12:48
*** rushiagr_away is now known as rushiagr12:49
ikhudoshynisviridov, hi there12:57
ikhudoshynisviridov, could u pls share that fancy link with AIs from the last meeting?12:57
ikhudoshynoops12:58
ikhudoshynu've just done it12:58
*** achuprin_ has joined #magnetodb12:58
isviridovikhudoshyn, hi. Yep it is in agenda12:59
achuprin_Hi team!12:59
dukhlovhello12:59
isviridovHello dukhlov13:00
isviridov#startmeeting magnetodb13:00
openstackMeeting 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
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.13:00
openstackThe meeting name has been set to 'magnetodb'13:00
isviridovWho is here?13:00
isviridovo/13:00
achudnovetshello everybody13:00
isviridovachudnovets, hello alex13:00
*** SpyRay has joined #magnetodb13:00
rushiagrhello!13:00
rushiagrajaya should be around too. Wait, I'll poke him13:01
isviridovSpyRay, hello13:01
SpyRayHi All!13:01
isviridovrushiagr, great. He has several items in agenda13:01
*** ajayaa has joined #magnetodb13:01
isviridovHello ajayaa13:02
ajayaaHi isviridov.13:02
isviridovOk, I think we can start13:02
isviridovHere is today agenda #link https://wiki.openstack.org/wiki/MagnetoDB/WeeklyMeetingAgenda#Agenda13:03
isviridovThe AIs from last meeting #link http://eavesdrop.openstack.org/meetings/magnetodb/2014/magnetodb.2014-10-02-13.00.html13:03
isviridov#topic Go through action items13:03
*** SpyRay has left #magnetodb13:03
*** SpyRay has joined #magnetodb13:03
isviridovdukhlov ikhudoshyn review spec for https://blueprints.launchpad.net/magnetodb/+spec/monitoring-health-check13:04
isviridovdukhlov, ikhudoshyn any success with it?13:04
ikhudoshynyup13:04
*** keith_newstadt has joined #magnetodb13:04
ikhudoshynin fact there was only one open question for me13:04
ikhudoshynresponse in case of unhealthy state13:05
dukhlovyes13:05
dukhlovnow it is returned 50313:05
ikhudoshyni would really like errcode other than 200 in the case13:05
aostapenkoikhudoshyn 50313:05
dukhlovand json response13:05
ikhudoshynaostapenko, is it official?13:05
dukhlovwith detailes13:05
aostapenkoikhudoshyn, yes. and text/plain body13:06
ikhudoshynaostapenko, great if so13:06
ikhudoshynno objections from my side than13:06
dukhlovbut if we decided that it is "simple" healthcheck13:06
isviridovikhudoshyn, dukhlov please add your 'approved' to spec, just to keep it consistent13:07
dukhlovand we have no plans to parse json to get detailes13:07
aostapenkothere is simple healthcheck, and healthcheck that checks subsystems. see specs please13:07
ikhudoshynisviridov, where to?13:07
aostapenkohttps://wiki.openstack.org/wiki/MagnetoDB/specs/monitoring-health-check13:07
ikhudoshynisviridov, i mean approve?13:07
dukhlovmaybe it is reasonable to return more detailed status via status code?13:07
isviridovikhudoshyn, https://wiki.openstack.org/wiki/MagnetoDB/specs/monitoring-health-check#Specification_status13:08
dukhlovI mean define a few codes for different cases13:08
ikhudoshynisviridov, tnx13:08
isviridovdukhlov, for example?13:09
ikhudoshyndukhlov, are we to provide automatic recovery? if no then I don't see a usecase for that13:09
aostapenkoI think 200 and 503 are enough13:10
dukhlovthat is ok, but In this case It is not clear for me why are we sending json with detailes?13:10
ikhudoshynaostapenko, +113:11
aostapenkodukhlov, plain/text. Just to provide additional info for administrator13:12
dukhlovaostapenko: ah, ok, I fogot that it is not REST call now13:12
isviridovOk, let us move on13:13
isviridovdukhlov, ok?13:13
ikhudoshynisviridov, +113:13
dukhlovok13:13
isviridovikhudoshyn dukhlov review https://wiki.openstack.org/wiki/MagnetoDB/specs/rbac13:13
isviridovLet me share my feedback also13:14
ikhudoshynas for that, I'd love to see full list of permissions13:14
* isviridov ikhudoshyn is faster13:14
isviridovyeap13:14
ajayaaApart from permission based on roles and projects(tenants) do we need anythin else?13:14
ikhudoshynajayaa, I dont see any13:15
ikhudoshyn* anything13:15
isviridovajayaa, could you enumerate the list of actions we are going to restrict13:15
ajayaaThen the permission listed in the spec are enough.13:15
ajayaaOkay.13:15
dukhlovLGTM in general, but i have seen there some kind of definition of simple language for rights13:16
ajayaaWe can restrict all actions.13:16
ajayaaIf you want to make an api public then just don't put any rule for it policy.json file.13:16
*** charlesw has joined #magnetodb13:16
ajayaaI will provide an example of that in the commit log.13:16
dukhlovrole:admin and project_id:(project_id)s13:16
dukhlovnow we have "AND"13:17
*** SpyRay has quit IRC13:17
dukhlovDo we plan to have "OR"13:17
ajayaadukhlov, yes.13:17
ajayaaIt is already there in policy.13:17
ajayaaThe openstack common code provided already does this.13:17
*** avinogradov has joined #magnetodb13:18
isviridovajayaa, yes. But the actions will be coded, so having a list will help to document exact maning13:18
isviridov*naming13:18
ajayaaOkay. I will modify the spec to reflect the same.13:18
isviridovThank you13:18
dukhlovajayaa:  openstack common code? which library? where can I find it?13:19
ajayaaIf you see my patch there itself, magnetodb/openstack/common/policy.py13:20
ajayaaThat is the common code shared by every project which does role based policy checking.13:21
isviridovajayaa, another think could you please keep the template structure. I mean https://wiki.openstack.org/wiki/MagnetoDB/specs/template13:21
ajayaaisviridov, I have missed some points in the template, I think.13:22
ajayaaI will update the spec. :)13:22
ikhudoshynajayaa, we're trying to get rid of *.openstack.common when possible13:22
dukhlovajayaa: cool, thank you13:23
ikhudoshynif u know a library where this stuff resides could u pls use it?13:23
ajayaaikhudoshyn, There is no library for it as of now.13:23
ikhudoshynajayaa, ok ic13:23
ajayaaIn future oslo people could include it, but I am sure.13:23
achudnovetsikhudoshyn: https://github.com/openstack/oslo-incubator/blob/master/openstack/common/policy.py13:23
* isviridov came back13:24
isviridovdukhlov, ikhudoshyn next point?13:24
dukhlov+113:24
ikhudoshynachudnovets, are we to see oslo.incubator on pypi?13:24
ikhudoshynachudnovets, in some future?13:24
achudnovetsIt may become a library some day :)13:25
ikhudoshyn:) tnx13:25
ikhudoshynikhudoshyn, lets move on13:25
isviridovisviridov start create spec repo like https://github.com/openstack/nova-specs13:25
ajayaaikhudoshyn, Before becoming library common code go thorough oslo.incubator.13:25
ikhudoshyns/ikhudoshyn/isviridov13:25
isviridovIt is for me. So no progress here yet13:26
ikhudoshynajayaa, that makes sense, i just dont really like copypased code13:26
isviridovBut we will have it for kilo13:26
ikhudoshynisviridov, we're ;looking forward ))13:27
isviridovikhudoshyn, :)13:27
isviridovominakov describe security impact here https://wiki.openstack.org/wiki/MagnetoDB/specs/monitoring-api13:27
isviridovominakov, around?13:27
isviridovOk.We have other point to discuss13:28
ajayaaikhudoshyn, If everybody feels like we should wait for policies to become a library, then I am fine with it. :)13:28
ikhudoshynajayaa, no way)13:28
achudnovetsisviridov: +1 :)13:28
isviridovajayaa, how long it can take?13:29
ajayaaisviridov, I have no idea.13:29
isviridovWe had the same with notifications, I don't think that it should stop us.13:30
isviridovOr even more, it is a greate chance to contribute to oslo13:30
ajayaaYes. besides every other project is reusing that piece of code.13:31
isviridovajayaa, yeap13:31
isviridovOk next big topic looks like from you13:31
isviridov#topic Decide how to do metering. Define a clear boundary between monitoring api and Ceilometer metering through Magnetodb notifications.13:31
isviridov#topic Decide how to do metering13:32
ajayaaDo we have a basic idea of what to meter?13:32
ajayaabesides byte usage and #rows in a table13:32
keith_newstadtwe have docs describing key metrics13:33
keith_newstadthave that info been shared with the community?13:33
ajayaaI don't see it.13:33
keith_newstadtwe should put it in the blueprint13:34
isviridovkeith_newstadt, 1 sec13:34
isviridovHere it is #link https://docs.google.com/a/mirantis.com/spreadsheets/d/1tYvgCSvkcOVED46MX8qSlUyrhNhHlyTrVkX7AXP-XR4/edit#gid=013:34
isviridovHere is the list13:35
isviridovajayaa, does it work for you?13:35
ajayaayep. I can see it.13:35
isviridovSo the data with Source API==KVaaS API is expected to be collected with monitoring API13:37
ikhudoshynisviridov, and everything other is left for ceilometer?13:38
ajayaaCeilometer would only consume notifications as of now.13:38
isviridovajayaa, what about pooling data?13:39
ajayaaIf we are going to do metering through ceilometer then we should emit notifications containing these information.13:39
ajayaaI talked with ceilometer devs and they are okay with notifications but not polling.13:39
isviridovajayaa, I mean pollster http://docs.openstack.org/developer/ceilometer/contributing/plugins.html#pollster13:39
isviridovWhat the reasoning to work only with notifications?13:40
isviridovikhudoshyn, actually all can be sent to celiometer, the question is how and if it is needed there at all13:41
ajayaaisviridov, no dependency on code of other modules.13:42
ajayaaservices*13:42
isviridovajayaa, got you13:42
isviridovajayaa, yeap it is a big question for us as non integrated project. We have to figure out how we can go here13:43
isviridovOk, let us summarize13:43
ajayaaWe could have some code running periodically which would send notifications.13:43
isviridov#info celiometer team prefers notifications13:44
isviridovajayaa, are you ok with a list of metrics or have ideas what we can add?13:45
ajayaaisviridov, I will go through the list in detail and let you know.13:45
isviridov#action ajayaa review current list of metrics13:46
isviridovAnything else>13:46
isviridov?13:46
ikhudoshynisviridov, move on?13:46
isviridovajayaa, keith_newstadt move on?13:46
ajayaaokay.13:46
isviridov#topic UUID for a table13:47
ajayaaThe need for this right now is in ceilometer which needs a field resource_id.13:47
isviridovajayaa, I believe celiometer is a big topic, let us continue offline. But very appreciate your work!13:47
ajayaawhich should be unique per resouce which is being measured.13:48
ajayaaokay.13:48
ajayaaAlso UUID would help in making our apis more openstack way.13:49
isviridovI personally would like to see UUID for table13:49
isviridovdukhlov, ikhudoshyn, charlesw any thoughts?13:49
ajayaaisviridov, yes.13:49
ajayaa+113:49
ikhudoshynisviridov, where exactly u want to see them?13:49
isviridovAs table attribute13:50
ikhudoshynis it only about haivng them in table_info or u expect to expose it?13:50
ikhudoshynlike in resource url?13:50
ajayaaikhudoshyn, unless exposed what value would it add?13:50
ikhudoshynajayaa, that's what I tey to figure out)13:51
charleswtable name + project id is already unique. What's the purpose for uuid for table?13:51
ikhudoshyncharlesw, +113:52
keith_newstadtcharlesw +113:52
aostapenkocharlesw, table can be recreated13:52
ajayaaaostapenko +113:52
aostapenkoand it will be another resource13:52
ajayaaI was waiting for you to tell this. :)13:52
keith_newstadthow would the user use the uuid?13:53
dukhlovtable name + project id is already unique in scope of magnetodb13:53
keith_newstadti'm trying to understand the use case we'd be solving for13:53
aostapenkodukhlov, but not in scope of OpenStack. If we consider a table as a resource13:53
dukhlovsould this ID be unique resoure for monitoring in scope of all ceilometer resoures being monitored13:54
dukhlov?13:54
ajayaadukhlov, yes. At least for one service.13:54
aostapenkoIt's not a problem to add uuid just for ceilometer. but it will be openstack style if we expose it13:57
isviridovHEAT has similar story. Implementing AWS CloudFormation API they have as stack name as identifier, but added UUID as well13:58
isviridovhttp://developer.openstack.org/api-ref-orchestration-v1.html13:58
isviridovIt looks like we don't have an agreement here. Let us return back to it offline or in ML13:59
ikhudoshynso for ceilometer we could have table name + uuid as a resource id13:59
charleswThen we need to change MDB resource url to use uuid instead of table name. Different than Dynamo13:59
ikhudoshyncharlesw, OS REST API already differs from Dynamo one13:59
ikhudoshynbut this is a topic to discuss anyway14:00
isviridovWe are run out of time14:00
isviridov#topic Juno delivery status overview14:00
isviridovThe current rc1 is the last version before juno release14:01
isviridovI've created kilo and we can start with suggesting BPs there https://launchpad.net/magnetodb/kilo14:01
isviridovThank you for attending the meeting.14:02
isviridov#stopmeeting14:02
rushiagrthanks all14:02
rushiagrisviridov: endmeeting :)14:02
isviridov#endmeeting14:02
openstackMeeting ended Thu Oct  9 14:02:41 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:02
openstackMinutes:        http://eavesdrop.openstack.org/meetings/magnetodb/2014/magnetodb.2014-10-09-13.00.html14:02
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/magnetodb/2014/magnetodb.2014-10-09-13.00.txt14:02
openstackLog:            http://eavesdrop.openstack.org/meetings/magnetodb/2014/magnetodb.2014-10-09-13.00.log.html14:02
isviridovrushiagr, thanks14:02
isviridov:))14:02
rushiagr:)14:02
*** ajayaa has quit IRC14:24
*** ajayaa has joined #magnetodb14:27
*** avinogradov has quit IRC14:32
*** vivekd has quit IRC14:35
openstackgerritAndrei V. Ostapenko proposed a change to stackforge/magnetodb: Changes logic of table cleanup in tempest  https://review.openstack.org/12721614:39
*** k4n0 has quit IRC14:42
*** isviridov is now known as isviridov_meet14:43
*** jeromatron has joined #magnetodb14:53
*** romainh has left #magnetodb14:59
openstackgerritAndrei V. Ostapenko proposed a change to stackforge/magnetodb: Changes logic of table cleanup in tempest  https://review.openstack.org/12721615:08
*** jeromatron has quit IRC15:12
*** jeromatron has joined #magnetodb15:15
*** keith_newstadt has quit IRC15:33
*** isviridov_meet is now known as isviridov_away15:34
openstackgerritAndrei V. Ostapenko proposed a change to stackforge/magnetodb: Changes logic of table cleanup in tempest  https://review.openstack.org/12721615:44
*** jeromatron has quit IRC16:38
*** jeromatron has joined #magnetodb16:42
*** jeromatron has quit IRC17:08
*** jeromatron has joined #magnetodb17:09
*** jeromatron has quit IRC17:52
*** jeromatron has joined #magnetodb18:22
*** jeromatron has quit IRC18:57
*** rushiagr is now known as rushiagr_away19:00
*** jeromatron has joined #magnetodb19:01
*** jeromatron has quit IRC19:06
*** jeromatron has joined #magnetodb19:09
openstackgerritA change was merged to stackforge/magnetodb: Use oslo.notify for notifications  https://review.openstack.org/12648919:12
*** jeromatron has quit IRC19:33
*** jeromatron has joined #magnetodb19:41
*** ajayaa has quit IRC19:45
openstackgerritNuno Santos proposed a change to stackforge/magnetodb: Additional validation on keyspace, index, table, and attribute names  https://review.openstack.org/12544521:35
openstackgerritNuno Santos proposed a change to stackforge/magnetodb: Additional validation on keyspace, index, table, and attribute names  https://review.openstack.org/12544521:43
*** charlesw has quit IRC22:36
*** jeromatron has quit IRC23:17
*** jeromatron has joined #magnetodb23:49

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!