Thursday, 2014-12-04

*** jeromatron has quit IRC00:01
*** charlesw has joined #magnetodb01:13
*** charlesw has quit IRC02:38
*** charlesw has joined #magnetodb02:42
*** charlesw has quit IRC02:47
*** vivekd has joined #magnetodb03:04
*** charlesw has joined #magnetodb03:06
*** vivekd_ has joined #magnetodb04:11
*** vivekd has quit IRC04:13
*** vivekd_ is now known as vivekd04:13
openstackgerritCharles Wang proposed stackforge/magnetodb-specs: Add request metrics speccification  https://review.openstack.org/13895004:26
*** charlesw has quit IRC04:40
*** rushiagr_away is now known as rushiagr04:48
*** vivekd has quit IRC04:52
*** vivekd has joined #magnetodb04:53
*** vivekd has quit IRC04:54
*** vivekd has joined #magnetodb04:55
*** vivekd has quit IRC04:57
*** vivekd has joined #magnetodb04:59
*** vivekd has joined #magnetodb05:00
*** vivekd has quit IRC05:00
*** vivekd has joined #magnetodb05:01
*** vivekd has quit IRC05:01
*** vivekd has joined #magnetodb05:02
*** ajayaa has joined #magnetodb05:45
*** jeromatron has joined #magnetodb06:09
*** vivekd_ has joined #magnetodb06:11
*** vivekd has quit IRC06:12
*** vivekd_ is now known as vivekd06:13
*** k4n0 has joined #magnetodb06:54
*** jeromatron has quit IRC07:20
*** achuprin_ has quit IRC07:29
*** jeromatron has joined #magnetodb07:33
*** achuprin_ has joined #magnetodb07:43
*** denis_makogon has joined #magnetodb07:59
*** jeromatron has quit IRC08:06
*** jeromatron has joined #magnetodb08:49
*** jeromatron has quit IRC08:50
*** vivekd has quit IRC08:51
*** jeromatron has joined #magnetodb08:56
*** romainh has joined #magnetodb09:17
*** jeromatron has quit IRC09:17
*** jeromatron has joined #magnetodb09:21
*** jeromatron has quit IRC09:23
*** jeromatron has joined #magnetodb09:26
*** jeromatron has quit IRC09:56
*** jeromatron has joined #magnetodb10:06
*** jeromatron has quit IRC10:11
openstackgerritOleksandr Minakov proposed stackforge/magnetodb: API URI format change  https://review.openstack.org/13805910:54
*** isviridov_away is now known as isviridov10:56
*** jeromatron has joined #magnetodb11:23
*** denis_makogon has quit IRC11:43
*** dmakogon_ is now known as denis_makogon11:44
*** denis_makogon_ has joined #magnetodb11:44
*** jeromatron has quit IRC11:50
*** denis_makogon_ has quit IRC11:51
openstackgerritOleksandr Minakov proposed stackforge/magnetodb: API URI format change  https://review.openstack.org/13805911:55
*** jeromatron has joined #magnetodb11:57
openstackgerritOleksandr Minakov proposed stackforge/magnetodb: Fixes doc according to API refactoring  https://review.openstack.org/13903512:21
openstackgerritOleksandr Minakov proposed stackforge/magnetodb: Fixes doc according to API refactoring  https://review.openstack.org/13903512:21
openstackgerritIlya Sviridov proposed stackforge/magnetodb: oslo.messaging update  https://review.openstack.org/13903812:36
isviridovHello everybody.12:40
isviridovWe have py27 job broken because of olso.messaging 1.5.0 release.12:40
openstackgerritIllia Khudoshyn proposed stackforge/magnetodb: (WIP)Add backup/restore REST API methods  https://review.openstack.org/13732812:40
isviridovShould be fixed with https://review.openstack.org/13903812:41
*** jeromatron has quit IRC12:41
*** isviridov changes topic to "MagnetoDB - key-value store for OpenStack (https://wiki.openstack.org/wiki/MagnetoDB, logs @ https://botbot.me/freenode/magnetodb/) | Our Kilo OpenStack summit design session http://goo.gl/czt5mL | Kilo roadmap http://goo.gl/XHXIpg | ask isviridov is any Qs | gate-magnetodb-python27 is broken. Should be fixed with https://review.openstack.org/139038"12:42
isviridovaostapenko agenda has been updated12:49
isviridovaostapenko I've just noticed your item and I believe that adding the links will be useful12:54
aostapenkoisviridov: yes, thank you12:54
*** Jon___ has joined #magnetodb13:55
openstackgerritAndrei V. Ostapenko proposed stackforge/magnetodb-specs: Adds table uuid in uri specification  https://review.openstack.org/13733613:57
isviridovHello everybody13:58
isviridovIt is meeting time13:59
achuprin_Hi team14:00
isviridovikhudoshyn dukhlov achudnovets aostapenko ominakov achuprin mdb meeting14:00
isviridov#startmeeting magnetodb14:00
openstackMeeting started Thu Dec  4 14:00:33 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
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:00
openstackThe meeting name has been set to 'magnetodb'14:00
isviridovHi everyone14:00
ominakovHello guys14:00
isviridovo/14:00
ominakovo/14:01
isviridovominakov hello14:01
achudnovetshi guys14:01
isviridovachudnovets welcome back14:01
ikhudoshyno/14:01
aostapenkoo/14:01
isviridovSo today meeting agenda is following https://wiki.openstack.org/wiki/MagnetoDB/WeeklyMeetingAgenda#Agenda14:02
isviridovI think we can start14:02
*** nunosantos has joined #magnetodb14:02
isviridov#topic Go through action items isviridov14:02
isviridovajayaa clarify auth in nova14:03
nunosantoso/14:03
isviridovhi nunosantos14:03
* isviridov doesn't see ajayaa14:03
isviridovLet us go through other topics14:04
isviridov#topic Add proposition to add availability to describe table by its uuid aostapenko14:04
*** avinogradov has joined #magnetodb14:04
isviridov#link https://review.openstack.org/13733614:05
isviridovaostapenko?14:05
aostapenkoplease review a specification shared by isviridov14:05
*** miqui_ has joined #magnetodb14:06
aostapenkowe are proposing to add an availability to use table uuid in any url, that contains table name14:06
ajayaaOh hi! Sorry, I am late.14:06
ajayaaI will update nova-auth in the end.14:07
aostapenkoand describe, create, delete and list operations will additionally contain table uuid14:07
ikhudoshynaostapenko: and we should add uuid in all tersponses that contain table info (describe, delete)14:07
ikhudoshynaostapenko: u were faster14:07
isviridovajayaa hi, we would love to hear from you14:07
ajayaanow?14:08
isviridovajayaa later14:08
aostapenkoDoes any body have any thoughts about it?14:08
ikhudoshynmy head has, actually14:09
isviridovAny changes in table list response?14:09
aostapenkoyes. It will additionally contain table name and id14:09
ikhudoshynisviridov: i wouldn't add uuid to table list14:09
*** charlesw has joined #magnetodb14:10
achudnovetsikhudoshyn: why?14:10
ikhudoshynuuid seems rather aux for me, with restricted usage14:11
achudnovetshow user then be able to find table id then?14:11
ikhudoshyndescribe table by name14:11
ikhudoshynwe'd allow describe by uuid as well14:11
ikhudoshyni think we should keep table name as a primary id and add uuid only as aux id14:12
aostapenkocreate table response also will contain table id14:12
ikhudoshyni expect uuid usage gonna be limited14:12
isviridovikhudoshyn +1 for keeping list_tables response as is14:12
isviridov#link http://magnetodb.readthedocs.org/en/latest/list_tables.html14:13
achudnovetsnova list shows IDs afaik14:13
aostapenkoalmost every OS components lists show IDs14:13
ikhudoshynthey use ID for regular node addressing14:13
achudnovetsyep14:13
ikhudoshynwe'll use names14:13
ikhudoshynlook, table name is wellunderstood by al db users and devs14:14
achudnovetsikhudoshyn: you can use name in nova in most cases14:14
ikhudoshyntable id is used for some very specific cases14:14
ikhudoshynachudnovets: the main consern is, we can't use both everywhere14:15
ikhudoshynso we should stick to one14:15
ikhudoshynand keep the other where we really need14:15
achudnovetsi see. It can confuse openstack users...14:16
charleswcan we try uuid, if not found, then use name?14:16
ikhudoshynhey, charlesw, glad to see you joined14:16
ikhudoshynwe'll do14:16
aostapenkocharles: we are going to do so14:16
charleswsorry morning traffic is bad14:16
ikhudoshynbut there are some places we wouldn't use ids14:16
ikhudoshynlike pagination and batches14:17
ikhudoshynso for that cases i suggest to use names only14:17
achudnovetsikhudoshyn: so url patterns will be v1/{project_id}/data/tables/{UUID or table_name} ^14:17
achudnovets?14:17
ikhudoshynyes14:17
achudnovetshm14:18
aostapenkoachudnovets: yep14:18
charleswwhat about give the choice to user. Add a property: idOrName14:18
ikhudoshyncharlesw: this wouldn't work for all cases14:18
isviridovcharlesw do you mean teh URI?14:19
charleswno, in the request body14:19
isviridovIt means changing the other parts of API, but now we have an extending.14:20
achudnovetsso how do you know that user provides UUID?14:20
aostapenkoachudnovets: UUID has a priority14:20
charleswor, can be in url as query parameter14:20
aostapenkofirst we are looking by uuid, if not found - by name14:21
isviridovcharlesw from other hand the table name is more convinient for usage, that UUID14:21
ikhudoshyncharlesw: we dont use query params14:21
achudnovetsit's ambiguous as for me14:21
ikhudoshynachudnovets: i agree14:22
ikhudoshyni'd actually forbid uuids in uris14:22
ikhudoshynand only add ability to lookup by uuid14:22
charlesw@ikhudoshyn, we do have request parameter, such as limit in listTables14:22
achudnovetsikhudoshyn: I agree. Forbid uuid or name. And we can use name in query params in GET requests. It's common way14:23
ikhudoshyncharlesw: yes14:23
ajayaaikhudoshyn, +1. I think we would be complicating things by adding uuid everywhere.14:23
ikhudoshynthere is special usecase where uuid is needed14:23
ikhudoshynand there should be a way to find table by uuid14:24
achudnovetsThen add filtering by UUID as filter in query params14:24
charlesw+1 for using name as default. If uuid is needed, give user the option to specify it in req body or req parameter14:24
ikhudoshynor just add a separate method to find by id14:25
charleswthat can clutter the API14:26
ikhudoshynand even more, we dont have a good uri for that)14:26
isviridovikhudoshyn +114:26
ajayaacharlesw, We can add a filter to list table.14:26
ikhudoshynajayaa: it's not about listing but about describing14:27
*** Chao_li has joined #magnetodb14:27
ikhudoshynlike GET .../data/tables/{name}14:27
isviridovLet us summarize and go to the next topic14:27
achudnovetsyep. Common way is to use id in query and be able to filter by name...14:27
isviridov#idea add lookup call by UUID14:28
ikhudoshynit's a common way for OS but not for a DB14:28
charlesw achudnovets, is this you talking about: GET .../data/tables/{string}?byName=true?14:29
isviridov#idea add uuid in describe table attribute14:29
achudnovetsno. I've speaking about /data/tables?uuid={string} or /data/tables?name={string} in list tables14:30
aostapenkoI think that it will should be more openstack, than DB14:30
aostapenkoAnd give the priority to UUID14:30
ikhudoshynaostapenko: sorry i dont follow you14:31
isviridov#idea data/tables?uuid={string}14:31
isviridovachudnovets +114:31
charleswachudnovets, that will have same url as listTables, not good14:31
isviridovachudnovets could you share it in specs?14:31
achudnovetsIt's for list tables14:31
ikhudoshyncharlesw: good point14:31
isviridovikhudoshyn agree14:32
achudnovetsfor describe table I'd like to see  /data/tables/{uuid}14:32
achudnovetsby default14:32
achudnovetsor /data/tables/{name} but not both14:32
*** k4n0 has quit IRC14:33
ikhudoshynachudnovets: there'd be an issue with that14:33
charleswwhat about GET .../data/tables/{string}?byName=true for describe by bane, GET .../data/tables/{string} for uuid14:33
charleswbane -> name14:33
ikhudoshyncharlesw: maybe vice versa,14:34
isviridovachudnovets charlesw aostapenko ikhudoshyn it seems the topic is wider, let us continue offline14:34
ikhudoshyn?byUUid=true14:34
ajayaa+1 for vice versa.14:34
aostapenko.../data/tables/{uuid or name} with uuid priority would be good14:34
charleswdepending on default behavior we like14:34
achudnovetsWhy we can't live it as it is :)?14:35
ikhudoshynwe need uuids sometimes14:35
aostapenkoachudnovets: we need that lookup14:35
ikhudoshynbut for real life i like names, too14:35
*** miqui_ has quit IRC14:36
isviridovachudnovets we are intducing UUID in order to identify the table across openstack, but don't have teh way to lookup by uuid now14:36
aostapenkoI started to like ?byUUid=true14:37
aostapenkoand only in describe14:37
isviridovaostapenko what is url if so?14:38
ikhudoshynisviridov: as it is now14:39
achudnovetsguys how about update table then?14:39
aostapenko GET .../data/tables/{uuid}?byUUid=true14:39
ikhudoshynachudnovets: as it is now14:39
achudnovetsWe'll have different urls for GET and PUT14:39
ikhudoshynas we do now14:39
isviridov#idea extend describe_table with GET .../data/tables/{uuid}?byUUid=true14:40
ikhudoshynwe use /data/tables/ for put and /data/tables/{name} for get14:40
ikhudoshynachudnovets: i assume put=create table14:40
achudnovetsikhudoshyn: disagree14:40
achudnovetswe have similar urls for get and delete14:40
ikhudoshynachudnovets: ?14:40
ikhudoshynit's true14:41
achudnovetsand we have no implementtion for update table now )14:41
achudnovetsso we have no url for it14:41
ikhudoshyni thought POST is update14:41
aostapenkoLets end with lookup by uuid14:41
isviridovaostapenko do you have answers now?14:41
aostapenkoand switch a topic14:41
isviridovaostapenko +1, what are your next steps?14:42
aostapenkoI assume an answer is GET .../data/tables/{uuid}?byUUid=true14:42
ikhudoshyn#idea aostapenko to finish the spec and then vote)14:42
aostapenkoso yes. I do14:42
isviridovAgreed14:42
aostapenkoikhudoshyn: ok14:42
isviridov#topic Add proposition to add rules to policy.json for service users(monitoring, admin API etc) and use domain scoped tokens. Depends on bp https://blueprints.launchpad.net/magnetodb/+spec/support-roles achudnovets14:42
ikhudoshynin fact we could vote by merging the speec14:42
isviridov#link https://blueprints.launchpad.net/magnetodb/+spec/support-roles14:42
isviridovachudnovets stage is your14:43
achudnovetsIt's just an idea to add specific rules to policy.json For service users, like monitoring14:43
ikhudoshynachudnovets: why not)14:44
achudnovetsSo we can add role "monitoring", assign this role to service user and login as this user with "doman" scope.14:45
ikhudoshynachudnovets: +114:45
isviridovachudnovets sounds good, are you going to implement it?14:45
achudnovetsYep I can. I depens on https://blueprints.launchpad.net/magnetodb/+spec/support-roles14:46
ajayaadomain scope?14:46
achudnovetsajayaa: yes14:46
achudnovetsI ->it's14:46
ajayaaWhy exactly domain scope?14:46
*** miqui_ has joined #magnetodb14:47
achudnovetswe have cases when user don't know tenant id's to make correct request14:47
achudnovetsfor example for monitoring API14:48
ajayaahttp://{host}:8480/v1/{project_id}/monitoring/tables/table_name14:48
ajayaaI think in this url we have project_id.14:48
achudnovetsyep.14:48
ikhudoshynajayaa: there is a refactoring in the line14:49
achudnovetsto monitor all tables user need have some role in all projects14:49
* isviridov greets miqui_14:49
miqui_hey isviridov14:49
ajayaaYes. That is not what we want. Agree.14:50
ajayaaI am sorry. I have not gone through refactoring work. Please add a spec when you implement this.14:50
ajayaaWe can discuss it there.14:50
isviridovachudnovets ajayaa I think we will have cluster monitoring data eventually, not pinned to any specific tenant14:51
charleswbut even if you have domain scoped token, you still have to add the monitoring user to all projects, right?14:51
ominakovajayaa, https://blueprints.launchpad.net/magnetodb/+spec/api-uri-format-change14:51
ominakovcharlesw, no14:51
achudnovetscharlesw: no, if projects are in one domain14:51
isviridovajayaa it was discussed last meeting14:52
charleswdo you have a pointer?14:52
charleswprobably tied to certain version of keystone14:53
ajayaacharlesw, keystone v3.14:53
isviridovCan we use unscoped token, but check teh role only. f.e. monitoring_admin14:53
ominakovcharlesw, with keystone v3 we can use one user with domain scoped token for operations in all tenants of this domain14:53
ajayaaisviridov, I am not sure there is an unscoped token with a role in it.14:53
charleswno, unscoped token can only be used to deal with keystone14:54
isviridovajayaa charlesw thx14:54
charleswominakov, have you tried it?14:54
ajayaaWho is going to use it? cluster monitoring api?14:55
achudnovetscharlesw: are you speaking about domain scoped tokens?14:55
charleswachudnovets, yes14:55
ajayaaThe mdb service provider or the end user?14:55
achudnovetscharlesw: I tried it on latest keystone.14:56
charleswservice provider I think14:56
ominakovcharlesw, achudnovets, i also tried it14:56
isviridovcharlesw +1, service provider14:56
ajayaaThen why limit it to a projects in a domain?14:57
ajayaaThe service provider should get stat for tables in all the projects.14:57
charleswcause we don't want to add monitoring user to every project14:58
isviridovThe problems sounds like - give a service provider a possibility to check mdb usage by specific tenant, all tenants, overall usage and statistics14:58
ominakovajayaa, we have all our projects (users of mdb) in one domain14:58
isviridovominakov it is specific case and can be different14:59
ajayaaisviridov +114:59
isviridovGuys we have 1 min left, I think we have to dig it deeper, the thing we see is auth via keystone is a pain for service providers.14:59
ajayaacharlesw, We don't have to.15:00
ajayaaHe can have the said role in any of the project and use that token.15:00
charleswbut only to the same domain15:00
isviridovMeeting is over, we can continue discussion15:00
isviridov#endmeeting15:01
openstackMeeting ended Thu Dec  4 15:01:03 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:01
openstackMinutes:        http://eavesdrop.openstack.org/meetings/magnetodb/2014/magnetodb.2014-12-04-14.00.html15:01
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/magnetodb/2014/magnetodb.2014-12-04-14.00.txt15:01
openstackLog:            http://eavesdrop.openstack.org/meetings/magnetodb/2014/magnetodb.2014-12-04-14.00.log.html15:01
achudnovetsSo to make it simple, the idea is to implement domain scoped tokens support. For service users or for others..15:01
charleswdo we have to implement anything? Keystone v3 already has it15:01
achudnovetsthe "implementation" is only adding specific rules to policy.json :)15:02
charleswgot it, thx15:02
ajayaaachudnovets, more precisely, support domain scoped token in cluster monitoring api?15:03
*** Chao_li has quit IRC15:04
achudnovetsajayaa: I don't know now. I need to check how we are going to change monitoring api. Think I missed a lot :)15:06
ajayaaAnyway I wanted to update everyone on nova's auth model.  The project_id in the url and project_id in token should match.15:06
ajayaaOtherwise it gives 400.15:06
ajayaaSo, you should have a role in every project in which you want to operate.15:07
ajayaaachudnovets, :)15:07
isviridovajayaa thank you for update15:08
ajayaaI think we could follow the same model. My earlier motivation for not enforcing this was to not have this restriction.15:08
ajayaaBut then this requires another call to keystone or fetching a list of projects and caching it.15:09
ajayaaSo in the spirit of not complicating things we could go with the restriction.15:09
ajayaaisviridov, aostapenko, What do you think?15:10
isviridovSeems I've mixed topics. Why do we need fetching all projects?15:10
isviridovSorry15:11
achudnovetsajayaa: I thought default auth is: user has correct role for project_id from url15:11
aostapenkoajayaa: I think we can check if tokens tenant is equal to tenant from url15:12
ajayaaisviridov, Just a bit of background. RIght now there is a restriction in mdb which matched project_id in url and project_id in the token.15:12
ajayaaaostapenko, +1 exactly.15:13
* isviridov is following ajayaa15:13
achudnovetsajayaa: actually now we have a stub for auth :)15:14
ajayaaI wanted to do away with that restriction and control everything from policy.json. But then we risk creating keyspaces corresponding to non-existent projects in keystone unless we check for its existence.15:14
ajayaaisviridov, I hope it is clear.15:15
isviridovajayaa yes, it is clear now.15:15
ajayaaachudnovets, That's nice.15:15
isviridovSo, we do add this enforcement and no additiona requests to keystone needed15:16
ajayaaYes.15:16
isviridovCool, thx15:16
achudnovetsI think we should check if project_id is the same AND user has correct role in this project15:16
ajayaaachudnovets, We will be doing that.15:16
ajayaaThe question was to whether we should enforce url's project_id=token's project_id.15:17
charleswachudnovets, ominakov, do you have the scripts to demo domain scoped token can be used to access any projects in the domain?15:17
achudnovetscharlesw: I have15:17
charleswif you can share, it will be great15:18
achudnovetssure15:18
ajayaaachudnovets, But only in keystone, not in other components I guess.15:18
ajayaaisviridov, Do you have some time to discuss ceilometer integration?15:19
*** ajayaa has quit IRC15:21
charleswguys, pls take a look at: https://review.openstack.org/138950 (request metrics bp). Would love to hear back from you.15:21
isviridovcharlesw will do15:22
charleswisviridov, thx15:22
isviridovajayaa yes :)15:23
*** jeromatron has joined #magnetodb15:23
isviridovjeromatron hello15:24
jeromatronHi, how are things going?15:24
isviridovAll right, thank you15:25
isviridovYou know we are building own custom seconrady index and we would love to have your eyes on it.15:25
isviridovIf you have time here it is https://review.openstack.org/#/c/107500/15:26
isviridovmiqui miqui_ how it is going?15:28
*** isviridov is now known as isviridov_break15:30
miqui_hi isviridov_break... am doing ok...busy as heck...15:33
miqui_...andin between stuff....learning magnetodb :)15:34
openstackgerritAndrei V. Ostapenko proposed stackforge/magnetodb-specs: Adds table uuid in uri specification  https://review.openstack.org/13733615:34
charleswmiqui_, we are in same TZ, feel free to ping me while isviridov is unavailable15:36
miqui_...awesome... thanks...15:37
*** avinogradov has quit IRC15:46
*** jeromatron has quit IRC16:04
*** miqui__ has joined #magnetodb16:15
*** jeromatron has joined #magnetodb16:15
*** miqui_ has quit IRC16:18
*** ajayaa has joined #magnetodb16:24
*** jeromatron has quit IRC16:32
*** romainh has left #magnetodb16:38
*** jeromatron has joined #magnetodb16:47
*** jeromatr_ has joined #magnetodb16:55
openstackgerritCharles Wang proposed stackforge/magnetodb-specs: Add request metrics speccification  https://review.openstack.org/13895017:02
*** jeromatron has quit IRC17:12
*** jeromatr_ has quit IRC17:24
*** openstackgerrit has quit IRC18:50
*** openstackgerrit has joined #magnetodb18:50
*** ajayaa has quit IRC18:59
*** rushiagr is now known as rushiagr_away19:38
*** jeromatron has joined #magnetodb20:00
*** openstackgerrit has quit IRC20:04
*** openstackgerrit has joined #magnetodb20:04
*** rushiagr_away is now known as rushiagr21:22
*** denis_makogon_ has joined #magnetodb21:51
*** achuprin_ has quit IRC22:25
*** nunosantos has quit IRC22:37
*** jeromatron has quit IRC22:37
*** charlesw has quit IRC22:49
*** miqui__ has quit IRC22:54
*** Jon___ has quit IRC22:56
*** denis_makogon_ has quit IRC23:12

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