Tuesday, 2014-09-30

*** charlesw has joined #magnetodb01:05
*** vivekd has joined #magnetodb03:28
*** jeromatron has joined #magnetodb03:33
*** jeromatron has quit IRC03:42
*** charlesw has quit IRC03:48
*** rushiagr_away is now known as rushiagr04:01
*** rushiagr is now known as rushiagr_away04:51
*** rushiagr_away is now known as rushiagr05:32
*** ajayaa has joined #magnetodb05:45
*** ajayaa has quit IRC06:17
*** k4n0 has joined #magnetodb06:27
*** vivekd_ has joined #magnetodb06:35
*** vivekd has quit IRC06:38
*** vivekd_ is now known as vivekd06:38
*** romainh has joined #magnetodb06:59
*** ajayaa has joined #magnetodb07:02
*** romainh has quit IRC07:07
*** romainh has joined #magnetodb07:07
isviridovGM everybody07:19
idegtiarovHi!07:25
isviridovHey idegtiarov07:30
isviridovHow it is going in celiometer?07:30
idegtiarovall run its course07:32
ajayaaHi all.08:11
isviridovHello ajayaa08:11
ajayaaHi isviridov.08:13
isviridovajayaa, how are your progress with celiometer?08:28
ajayaaisviridov, I am preparing a spec to ceilometer spec repo right now.08:29
ajayaaI have a working code also.(POC kind of thing)08:29
ajayaaNeed to refine it though.08:29
isviridovGreat to know. We have a guys from celio here as well08:30
isviridovI mean idegtiarov08:30
isviridovDon't hesistate to share the spec here also08:31
ajayaaSure.08:31
ajayaaI have a little doubt regarding to resource_id field in ceilometer samples.08:31
ajayaaidegtiarov,08:31
ajayaa^^08:31
ajayaaIn mdb we don't have a UUID for a table or ant other identifier which could be used for a resource field.08:32
isviridovIs i mandatory?08:33
isviridov*it08:33
ajayaaYes.08:34
idegtiarovYep its mandatory08:34
isviridovThere is a similar case with HEAT08:34
isviridovIn AWS the stack name is used for indentification, but in OpenStack it is UUID08:35
isviridovThey solved it with allowing to access by both.08:35
isviridovidegtiarov, do you know any other usecases where UUID is not available?08:36
isviridovajayaa, good point! I think it should be discussed with celio cores.08:40
ajayaaYes. I need to check in celio documentation regarding use of resource_id.08:41
ajayaaIf it it something not exposed by REST api then we can use a dummy value.08:42
idegtiarovisviridov: sorry I don't get the meaning of your question08:47
isviridovajayaa, however I think that having UUID for table is a good practice08:53
ajayaaIt is not too much of a overhead I guess to have a UUID for a table.08:54
ajayaaisviridov, Do we have other cases where a UUID could be useful?08:55
ajayaaI can think of one use case, In future we could expose an api to access table with "/UUID".08:56
ajayaaThat way user won't have to keep track of both project name and table name.08:56
isviridovSorry having troubles with connection it seems. Loosing your messages08:57
isviridovI think that UUID is always good thing.08:58
isviridovajayaa, will you create a BP for this?08:58
ajayaaisviridov, sure.08:59
*** ajayaa has quit IRC10:05
*** romainh has quit IRC10:13
*** ajayaa has joined #magnetodb10:29
ajayaaisviridov, idegtiarov here is the spec I have written for mdb-ceilo integration.10:38
ajayaahttps://github.com/ajayaa/python-akhada/blob/master/magnetodb-notifications.rst10:38
isviridovajayaa, i like it.10:57
isviridovHave you discussed it with celiometer team? I mean the prioritization10:58
isviridovBTW here is BP I've registered some time ago for monitoring of mdb by celiometer https://blueprints.launchpad.net/ceilometer/+spec/support-magnetodb10:59
isviridovI think the description should be corrected in order to keep scope smaller and finish first with processing of notifications.11:00
idegtiarovajayaa: I'll look at the spec11:03
ajayaaisviridov, Yesterday I was talking to ceilometer cores.11:04
ajayaaThey are fine with notifications from mdb.11:04
isviridovGreat!11:05
ajayaaisviridov, Please assign that blueprint to me.11:06
isviridovDone11:07
isviridovI also think that it will be useful to describe the metrics and events you are going to store to celio.11:08
isviridovF.e. like here https://github.com/openstack/ceilometer/commit/b27ac819fb2b6cd44d41dbaf71ba72805c6fe7d211:08
isviridovThe more detailed and clear the spec is, the esier it will be approved11:08
* isviridov or rejected11:08
ajayaaisviridov, I am yet to find out how to do aggregation in ceilometer.11:09
ajayaaI was hoping to get help from ceilometer team on that.11:09
ajayaaAnd this is just the initial draft of the spec. I plan on adding more stuff. :)11:10
isviridovajayaa, have you agreed any timeline for implementation? There is end if cycle now11:10
ajayaaYes. Kilo11:10
ajayaaNot in juno11:10
isviridovFeel free to ping me if any review needed or something11:11
ajayaasure. Thank you.11:11
isviridovBTW what are your plans about https://blueprints.launchpad.net/magnetodb/+spec/support-roles?11:14
isviridovajayaa, I'm thinking if we can do it during juno, but seems there is no spec at all ATM. Could you please share your plans on it?11:15
ajayaaisviridov, We have a spec for that.11:15
ajayaahttps://wiki.openstack.org/wiki/MagnetoDB/specs/rbac11:16
ajayaaI am doing that in my free time, besides office hours.11:16
isviridovAh, i remember, could you please add it to BP?11:16
isviridovajayaa, WOW work=hobby=OpenStack11:17
ajayaaisviridov, :)11:17
ajayaaisviridov, You could similarly assign that bp to me. :)11:18
isviridovajayaa, does it mean different SLAs for these patches? Do you think we have to introduce the tag 'hobby' or 'in-my-free-time'?11:18
ajayaaisviridov, if you feel the need for it!11:19
ajayaaI don't know.11:19
isviridovSure, done. You are drafter of it as well.11:19
isviridovThe only thing, please pay attention that according to priorities the first things to discuss and review are items in current development focus11:20
isviridovIn other words active milestone. Now it is https://launchpad.net/magnetodb/+milestone/juno-rc111:20
isviridovWith growing the team we are getting more capacity, so can extend the scope. But it should be agreed11:21
ajayaaWhen does juno milestone finish?11:22
isviridov16 of Oct11:22
ajayaaWe can put the role support in there, I should be able to finish it by then.11:23
ajayaaOnly the unittest part is there.11:24
isviridovI really would love to see it in juno.11:24
ajayaaI also would need to modify current unitests to be accomodating of policy files.11:24
ajayaaOr figure out a way to keep policy out of current unittests!11:25
isviridovI've added it to juno.11:27
isviridov Next step the spec should be approved by other core developers.11:27
isviridovIt the easiest way to get +2 for patch.11:28
isviridovI have some comments to spec right now11:29
ajayaaHow do I propose it for approval?11:30
ajayaaFeel free to express your concerns. :)11:31
isviridovFrom first look I think that all supported actions should be enumerated.11:38
isviridovAlso, please keep the template structure. If there is nothing to add out None https://wiki.openstack.org/wiki/MagnetoDB/specs/template11:38
isviridovYou can propose your BP or spec via mail list (preferable), IRC weekly meeting, here is IRC channel11:40
isviridov* in11:40
ajayaaI will make some changes to spec.11:41
aostapenkohttps://wiki.openstack.org/w/index.php?title=MagnetoDB/specs/monitoring-health-check11:43
aostapenkoHi guys, take a look please https://wiki.openstack.org/w/index.php?title=MagnetoDB/specs/monitoring-health-check11:44
isviridovLooks better now. What is the query to C* are yo going to use for?11:46
* isviridov feels sleepy11:49
isviridovaostapenko, could you specify it please in spec11:50
isviridovaostapenko, thank you11:50
isviridovaostapenko, having a meeting now. See you in 30mins11:50
aostapenkoisviridov, ok11:50
*** isviridov is now known as isviridov_away11:50
*** romainh has joined #magnetodb11:51
aostapenkoisviridov, done11:52
*** rushiagr is now known as rushiagr_away12:51
*** k4n0 has quit IRC13:01
*** isviridov_away is now known as isviridov13:06
isviridovaostapenko, with growing the number of tables, the request will be slower.  What about select * from magnetodb.table_info limit 1 ?13:19
*** rushiagr_away is now known as rushiagr13:24
*** rushiagr is now known as rushiagr_away13:36
*** charlesw has joined #magnetodb13:38
*** vivekd has quit IRC13:47
aostapenkoisviridov: great idea. thank you13:57
aostapenkoisviridov, ikhudoshyn, dukhlov, cwang look please and approve if you have no objections https://wiki.openstack.org/w/index.php?title=MagnetoDB/specs/monitoring-health-check13:59
*** rushiagr_away is now known as rushiagr14:19
*** ajayaa has quit IRC14:24
*** openstackgerrit has quit IRC14:42
*** jeromatron has joined #magnetodb15:23
*** openstackgerrit has joined #magnetodb15:25
openstackgerritAndrei V. Ostapenko proposed a change to stackforge/magnetodb: (WIP) Monitoring health check request  https://review.openstack.org/12510816:13
*** jeromatron has quit IRC16:24
*** jeromatron has joined #magnetodb16:28
*** jeromatron has quit IRC16:30
*** jeromatron has joined #magnetodb16:30
charleswaostapenko, the spec looks good mostly. A couple of things. healthcheck is a verb. Maybe health is more RESTful? Second is when status is ERROR, do you still return 200 HTTP response code? A different error code such as 500 can be potentially used by haproxy or other load balancer to mark the impacted API server as DOWN.16:32
*** jeromatron has quit IRC16:36
*** jeromatron has joined #magnetodb16:37
*** romainh has left #magnetodb16:48
*** romainh has joined #magnetodb16:49
*** jeromatron has quit IRC17:20
*** romainh has left #magnetodb17:33
*** rushiagr is now known as rushiagr_away17:48
*** rushiagr_away is now known as rushiagr17:51
*** openstackgerrit has quit IRC18:47
*** openstackgerrit has joined #magnetodb18:49
*** rushiagr is now known as rushiagr_away19:02
*** jeromatron has joined #magnetodb20:12
*** jeromatron has quit IRC20:23
*** jeromatron has joined #magnetodb20:23
*** jeromatron has quit IRC20:48
*** jeromatron has joined #magnetodb20:52
*** jeromatron has quit IRC21:10
*** jeromatron has joined #magnetodb21:11
*** jeromatron has quit IRC21:16
*** jeromatron has joined #magnetodb21:16
openstackgerritCharles Wang proposed a change to stackforge/magnetodb: Handle non-existent item when calling update_item  https://review.openstack.org/12392722:12
*** charlesw has quit IRC22:44
*** jeromatron has quit IRC23:13
*** jeromatron has joined #magnetodb23:17
*** jeromatron has quit IRC23:18

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