14:00:33 <isviridov> #startmeeting magnetodb
14:00:34 <openstack> Meeting 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:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:37 <openstack> The meeting name has been set to 'magnetodb'
14:00:55 <isviridov> Hi everyone
14:00:55 <ominakov> Hello guys
14:00:56 <isviridov> o/
14:01:01 <ominakov> o/
14:01:12 <isviridov> ominakov hello
14:01:16 <achudnovets> hi guys
14:01:25 <isviridov> achudnovets welcome back
14:01:27 <ikhudoshyn> o/
14:01:32 <aostapenko> o/
14:02:23 <isviridov> So today meeting agenda is following https://wiki.openstack.org/wiki/MagnetoDB/WeeklyMeetingAgenda#Agenda
14:02:43 <isviridov> I think we can start
14:02:58 <isviridov> #topic Go through action items isviridov
14:03:17 <isviridov> ajayaa clarify auth in nova
14:03:19 <nunosantos> o/
14:03:30 <isviridov> hi nunosantos
14:03:52 * isviridov doesn't see ajayaa
14:04:21 <isviridov> Let us go through other topics
14:04:45 <isviridov> #topic Add proposition to add availability to describe table by its uuid aostapenko
14:05:04 <isviridov> #link https://review.openstack.org/137336
14:05:07 <isviridov> aostapenko?
14:05:41 <aostapenko> please review a specification shared by isviridov
14:06:31 <aostapenko> we are proposing to add an availability to use table uuid in any url, that contains table name
14:06:48 <ajayaa> Oh hi! Sorry, I am late.
14:07:31 <ajayaa> I will update nova-auth in the end.
14:07:31 <aostapenko> and describe, create, delete and list operations will additionally contain table uuid
14:07:35 <ikhudoshyn> aostapenko: and we should add uuid in all tersponses that contain table info (describe, delete)
14:07:52 <ikhudoshyn> aostapenko: u were faster
14:07:52 <isviridov> ajayaa hi, we would love to hear from you
14:08:20 <ajayaa> now?
14:08:27 <isviridov> ajayaa later
14:08:55 <aostapenko> Does any body have any thoughts about it?
14:09:21 <ikhudoshyn> my head has, actually
14:09:22 <isviridov> Any changes in table list response?
14:09:55 <aostapenko> yes. It will additionally contain table name and id
14:09:56 <ikhudoshyn> isviridov: i wouldn't add uuid to table list
14:10:30 <achudnovets> ikhudoshyn: why?
14:11:00 <ikhudoshyn> uuid seems rather aux for me, with restricted usage
14:11:09 <achudnovets> how user then be able to find table id then?
14:11:22 <ikhudoshyn> describe table by name
14:11:35 <ikhudoshyn> we'd allow describe by uuid as well
14:12:23 <ikhudoshyn> i think we should keep table name as a primary id and add uuid only as aux id
14:12:39 <aostapenko> create table response also will contain table id
14:12:41 <ikhudoshyn> i expect uuid usage gonna be limited
14:12:43 <isviridov> ikhudoshyn +1 for keeping list_tables response as is
14:13:13 <isviridov> #link http://magnetodb.readthedocs.org/en/latest/list_tables.html
14:13:19 <achudnovets> nova list shows IDs afaik
14:13:45 <aostapenko> almost every OS components lists show IDs
14:13:49 <ikhudoshyn> they use ID for regular node addressing
14:13:52 <achudnovets> yep
14:13:54 <ikhudoshyn> we'll use names
14:14:20 <ikhudoshyn> look, table name is wellunderstood by al db users and devs
14:14:31 <achudnovets> ikhudoshyn: you can use name in nova in most cases
14:14:38 <ikhudoshyn> table id is used for some very specific cases
14:15:12 <ikhudoshyn> achudnovets: the main consern is, we can't use both everywhere
14:15:25 <ikhudoshyn> so we should stick to one
14:15:45 <ikhudoshyn> and keep the other where we really need
14:16:04 <achudnovets> i see. It can confuse openstack users...
14:16:12 <charlesw> can we try uuid, if not found, then use name?
14:16:32 <ikhudoshyn> hey, charlesw, glad to see you joined
14:16:37 <ikhudoshyn> we'll do
14:16:52 <aostapenko> charles: we are going to do so
14:16:55 <charlesw> sorry morning traffic is bad
14:16:55 <ikhudoshyn> but there are some places we wouldn't use ids
14:17:06 <ikhudoshyn> like pagination and batches
14:17:31 <ikhudoshyn> so for that cases i suggest to use names only
14:17:44 <achudnovets> ikhudoshyn: so url patterns will be v1/{project_id}/data/tables/{UUID or table_name} ^
14:17:48 <achudnovets> ?
14:17:59 <ikhudoshyn> yes
14:18:02 <achudnovets> hm
14:18:10 <aostapenko> achudnovets: yep
14:18:12 <charlesw> what about give the choice to user. Add a property: idOrName
14:18:32 <ikhudoshyn> charlesw: this wouldn't work for all cases
14:19:34 <isviridov> charlesw do you mean teh URI?
14:19:45 <charlesw> no, in the request body
14:20:20 <isviridov> It means changing the other parts of API, but now we have an extending.
14:20:21 <achudnovets> so how do you know that user provides UUID?
14:20:51 <aostapenko> achudnovets: UUID has a priority
14:20:59 <charlesw> or, can be in url as query parameter
14:21:11 <aostapenko> first we are looking by uuid, if not found - by name
14:21:31 <isviridov> charlesw from other hand the table name is more convinient for usage, that UUID
14:21:39 <ikhudoshyn> charlesw: we dont use query params
14:21:49 <achudnovets> it's ambiguous as for me
14:22:01 <ikhudoshyn> achudnovets: i agree
14:22:17 <ikhudoshyn> i'd actually forbid uuids in uris
14:22:41 <ikhudoshyn> and only add ability to lookup by uuid
14:22:54 <charlesw> @ikhudoshyn, we do have request parameter, such as limit in listTables
14:23:09 <achudnovets> ikhudoshyn: I agree. Forbid uuid or name. And we can use name in query params in GET requests. It's common way
14:23:12 <ikhudoshyn> charlesw: yes
14:23:19 <ajayaa> ikhudoshyn, +1. I think we would be complicating things by adding uuid everywhere.
14:23:57 <ikhudoshyn> there is special usecase where uuid is needed
14:24:17 <ikhudoshyn> and there should be a way to find table by uuid
14:24:32 <achudnovets> Then add filtering by UUID as filter in query params
14:24:37 <charlesw> +1 for using name as default. If uuid is needed, give user the option to specify it in req body or req parameter
14:25:23 <ikhudoshyn> or just add a separate method to find by id
14:26:03 <charlesw> that can clutter the API
14:26:33 <ikhudoshyn> and even more, we dont have a good uri for that)
14:26:43 <isviridov> ikhudoshyn +1
14:26:52 <ajayaa> charlesw, We can add a filter to list table.
14:27:18 <ikhudoshyn> ajayaa: it's not about listing but about describing
14:27:32 <ikhudoshyn> like GET .../data/tables/{name}
14:27:33 <isviridov> Let us summarize and go to the next topic
14:27:41 <achudnovets> yep. Common way is to use id in query and be able to filter by name...
14:28:06 <isviridov> #idea add lookup call by UUID
14:28:07 <ikhudoshyn> it's a common way for OS but not for a DB
14:29:14 <charlesw> achudnovets, is this you talking about: GET .../data/tables/{string}?byName=true?
14:29:27 <isviridov> #idea add uuid in describe table attribute
14:30:25 <achudnovets> no. I've speaking about /data/tables?uuid={string} or /data/tables?name={string} in list tables
14:30:27 <aostapenko> I think that it will should be more openstack, than DB
14:30:57 <aostapenko> And give the priority to UUID
14:31:01 <ikhudoshyn> aostapenko: sorry i dont follow you
14:31:11 <isviridov> #idea data/tables?uuid={string}
14:31:16 <isviridov> achudnovets +1
14:31:23 <charlesw> achudnovets, that will have same url as listTables, not good
14:31:34 <isviridov> achudnovets could you share it in specs?
14:31:40 <achudnovets> It's for list tables
14:31:42 <ikhudoshyn> charlesw: good point
14:32:12 <isviridov> ikhudoshyn agree
14:32:21 <achudnovets> for describe table I'd like to see  /data/tables/{uuid}
14:32:29 <achudnovets> by default
14:32:56 <achudnovets> or /data/tables/{name} but not both
14:33:18 <ikhudoshyn> achudnovets: there'd be an issue with that
14:33:34 <charlesw> what about GET .../data/tables/{string}?byName=true for describe by bane, GET .../data/tables/{string} for uuid
14:33:51 <charlesw> bane -> name
14:34:13 <ikhudoshyn> charlesw: maybe vice versa,
14:34:17 <isviridov> achudnovets charlesw aostapenko ikhudoshyn it seems the topic is wider, let us continue offline
14:34:20 <ikhudoshyn> ?byUUid=true
14:34:24 <ajayaa> +1 for vice versa.
14:34:32 <aostapenko> .../data/tables/{uuid or name} with uuid priority would be good
14:34:48 <charlesw> depending on default behavior we like
14:35:13 <achudnovets> Why we can't live it as it is :)?
14:35:29 <ikhudoshyn> we need uuids sometimes
14:35:44 <aostapenko> achudnovets: we need that lookup
14:35:50 <ikhudoshyn> but for real life i like names, too
14:36:47 <isviridov> achudnovets we are intducing UUID in order to identify the table across openstack, but don't have teh way to lookup by uuid now
14:37:28 <aostapenko> I started to like ?byUUid=true
14:37:47 <aostapenko> and only in describe
14:38:22 <isviridov> aostapenko what is url if so?
14:39:02 <ikhudoshyn> isviridov: as it is now
14:39:04 <achudnovets> guys how about update table then?
14:39:07 <aostapenko> GET .../data/tables/{uuid}?byUUid=true
14:39:17 <ikhudoshyn> achudnovets: as it is now
14:39:28 <achudnovets> We'll have different urls for GET and PUT
14:39:40 <ikhudoshyn> as we do now
14:40:05 <isviridov> #idea extend describe_table with GET .../data/tables/{uuid}?byUUid=true
14:40:08 <ikhudoshyn> we use /data/tables/ for put and /data/tables/{name} for get
14:40:28 <ikhudoshyn> achudnovets: i assume put=create table
14:40:33 <achudnovets> ikhudoshyn: disagree
14:40:53 <achudnovets> we have similar urls for get and delete
14:40:53 <ikhudoshyn> achudnovets: ?
14:41:08 <ikhudoshyn> it's true
14:41:13 <achudnovets> and we have no implementtion for update table now )
14:41:23 <achudnovets> so we have no url for it
14:41:29 <ikhudoshyn> i thought POST is update
14:41:41 <aostapenko> Lets end with lookup by uuid
14:41:45 <isviridov> aostapenko do you have answers now?
14:41:48 <aostapenko> and switch a topic
14:42:07 <isviridov> aostapenko +1, what are your next steps?
14:42:08 <aostapenko> I assume an answer is GET .../data/tables/{uuid}?byUUid=true
14:42:12 <ikhudoshyn> #idea aostapenko to finish the spec and then vote)
14:42:13 <aostapenko> so yes. I do
14:42:23 <isviridov> Agreed
14:42:28 <aostapenko> ikhudoshyn: ok
14:42:39 <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 achudnovets
14:42:48 <ikhudoshyn> in fact we could vote by merging the speec
14:42:54 <isviridov> #link https://blueprints.launchpad.net/magnetodb/+spec/support-roles
14:43:33 <isviridov> achudnovets stage is your
14:43:42 <achudnovets> It's just an idea to add specific rules to policy.json For service users, like monitoring
14:44:56 <ikhudoshyn> achudnovets: why not)
14:45:01 <achudnovets> So we can add role "monitoring", assign this role to service user and login as this user with "doman" scope.
14:45:14 <ikhudoshyn> achudnovets: +1
14:45:49 <isviridov> achudnovets sounds good, are you going to implement it?
14:46:11 <achudnovets> Yep I can. I depens on https://blueprints.launchpad.net/magnetodb/+spec/support-roles
14:46:25 <ajayaa> domain scope?
14:46:39 <achudnovets> ajayaa: yes
14:46:53 <achudnovets> I ->it's
14:46:55 <ajayaa> Why exactly domain scope?
14:47:51 <achudnovets> we have cases when user don't know tenant id's to make correct request
14:48:07 <achudnovets> for example for monitoring API
14:48:32 <ajayaa> http://{host}:8480/v1/{project_id}/monitoring/tables/table_name
14:48:43 <ajayaa> I think in this url we have project_id.
14:48:47 <achudnovets> yep.
14:49:10 <ikhudoshyn> ajayaa: there is a refactoring in the line
14:49:16 <achudnovets> to monitor all tables user need have some role in all projects
14:49:29 * isviridov greets miqui_
14:49:41 <miqui_> hey isviridov
14:50:06 <ajayaa> Yes. That is not what we want. Agree.
14:50:40 <ajayaa> I am sorry. I have not gone through refactoring work. Please add a spec when you implement this.
14:50:45 <ajayaa> We can discuss it there.
14:51:10 <isviridov> achudnovets ajayaa I think we will have cluster monitoring data eventually, not pinned to any specific tenant
14:51:26 <charlesw> but even if you have domain scoped token, you still have to add the monitoring user to all projects, right?
14:51:35 <ominakov> ajayaa, https://blueprints.launchpad.net/magnetodb/+spec/api-uri-format-change
14:51:48 <ominakov> charlesw, no
14:51:57 <achudnovets> charlesw: no, if projects are in one domain
14:52:09 <isviridov> ajayaa it was discussed last meeting
14:52:32 <charlesw> do you have a pointer?
14:53:11 <charlesw> probably tied to certain version of keystone
14:53:21 <ajayaa> charlesw, keystone v3.
14:53:25 <isviridov> Can we use unscoped token, but check teh role only. f.e. monitoring_admin
14:53:44 <ominakov> charlesw, with keystone v3 we can use one user with domain scoped token for operations in all tenants of this domain
14:53:47 <ajayaa> isviridov, I am not sure there is an unscoped token with a role in it.
14:54:00 <charlesw> no, unscoped token can only be used to deal with keystone
14:54:13 <isviridov> ajayaa charlesw thx
14:54:55 <charlesw> ominakov, have you tried it?
14:55:30 <ajayaa> Who is going to use it? cluster monitoring api?
14:55:31 <achudnovets> charlesw: are you speaking about domain scoped tokens?
14:55:47 <charlesw> achudnovets, yes
14:55:51 <ajayaa> The mdb service provider or the end user?
14:56:14 <achudnovets> charlesw: I tried it on latest keystone.
14:56:22 <charlesw> service provider I think
14:56:52 <ominakov> charlesw, achudnovets, i also tried it
14:56:52 <isviridov> charlesw +1, service provider
14:57:18 <ajayaa> Then why limit it to a projects in a domain?
14:57:44 <ajayaa> The service provider should get stat for tables in all the projects.
14:58:02 <charlesw> cause we don't want to add monitoring user to every project
14:58:09 <isviridov> The problems sounds like - give a service provider a possibility to check mdb usage by specific tenant, all tenants, overall usage and statistics
14:58:40 <ominakov> ajayaa, we have all our projects (users of mdb) in one domain
14:59:03 <isviridov> ominakov it is specific case and can be different
14:59:13 <ajayaa> isviridov +1
14:59:59 <isviridov> Guys 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.
15:00:01 <ajayaa> charlesw, We don't have to.
15:00:23 <ajayaa> He can have the said role in any of the project and use that token.
15:00:46 <charlesw> but only to the same domain
15:00:58 <isviridov> Meeting is over, we can continue discussion
15:01:03 <isviridov> #endmeeting