19:00:07 <catherineD> #startmeeting refstack 19:00:07 <openstack> Meeting started Mon Jan 18 19:00:07 2016 UTC and is due to finish in 60 minutes. The chair is catherineD. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:10 <openstack> The meeting name has been set to 'refstack' 19:02:16 <rockyg> o/ 19:02:32 <pvaneck> o/ 19:02:33 <catherineD> rockyg: hello.. 19:02:39 <hogepodge> o/ 19:02:52 <alexandrelevine> o/ 19:02:59 <sslypushenko> o/ 19:03:03 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-01-18 19:03:19 <catherineD> hello everyone ... 19:03:38 <andrey-mp> o/ 19:04:33 <catherineD> I think we finally get the ball rolling for the Vendor Registration Process tasks ... thx to alexandrelevine: and andrey-mp: ... 19:05:02 <rockyg> ++ 19:05:14 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-01-18 19:05:56 <catherineD> #topic DefCore Meeting Jan 13, 2016 19:06:51 <catherineD> #link I requested DefCore to review Alex's requirement doc https://goo.gl/bvo4FG 19:07:25 <alexandrelevine> catherineD: Thank you. That's good to hear. 19:07:34 <catherineD> alexandrelevine: could you allow DefCore core member to add comments to the doc 19:07:56 <alexandrelevine> Absolutely, give me the emails 19:08:40 <catherineD> sure rockyg: hogepodge: could you send alexandrelevine: your gmail? 19:08:58 <catherineD> not sure gmail is really needed ... or any email will do? 19:09:02 <rockyg> it's the mailing list. hold a sec. Or Ican send to the list... 19:09:26 <rockyg> any will do. you just need the link. 19:09:28 <hogepodge> catherineD: my openstack e-mail can read google documents 19:09:30 <catherineD> rockyg: I think Chris, Mark, Egle and Rob will do ... 19:09:38 <catherineD> for now 19:09:40 <alexandrelevine> I can share it with everybody to allow editing if you want 19:09:50 <catherineD> alexandrelevine: that would be great 19:10:15 <alexandrelevine> Everyone can comment now 19:10:35 <catherineD> alexandrelevine: DefCore alsop would like to have a summary in Etherpad of the items that RefStack would like DefCore to review. 19:11:32 <catherineD> alexandrelevine: can you and I create and Etherpad before next DefCore meeting on Wed? 19:12:30 <catherineD> #link After DefCore review the Etherpad we will request for Mark to update https://review.openstack.org/#/c/226902/ 19:12:44 <catherineD> all good? 19:13:09 <catherineD> moving to the next topic ... 19:13:09 <pvaneck> sure 19:13:15 <catherineD> #topic RefStack implementation of Vendor Registration Process 19:13:23 <rockyg> Also, if you want to join the defcore list and just open the doc to people with the link, the ML is: defcore-committee@lists.openstack.org 19:14:00 <alexandrelevine_> Sorry, I lost my connection and missed a couple of minutes. 19:15:18 <catherineD> alexandrelevine_: we are onto the next topic in the agenda .. 19:15:27 <alexandrelevine_> perfect 19:15:49 <catherineD> #link Data model specs https://review.openstack.org/#/c/268922/ 19:16:00 <catherineD> #link https://review.openstack.org/#/c/269184/ 19:16:40 <catherineD> Let's discuss the comment in https://review.openstack.org/#/c/268922/ 19:17:16 <catherineD> Doe we want to add a role attribute at this time ? 19:18:17 <catherineD> please see comment in line 57 of https://review.openstack.org/#/c/268922/ 19:19:08 <alexandrelevine_> I just added a comment. 19:19:15 <alexandrelevine_> I'm still against it altogether. 19:19:44 <alexandrelevine_> I explained that regular Vendor users will be achieved by adding another built-in group ID (Users group) into Vendor record. 19:19:45 <sslypushenko> catherineD: I'm little bit confusing from idea to get rid of user role... I saw some related discussion in comments but still can't get a point 19:20:04 <alexandrelevine_> All of the Users in that Group will have non-admin rigths. No explicit roles required. 19:20:34 <sslypushenko> That is mean that group can not have 2 admins? 19:20:35 <catherineD> alexandrelevine_: you mean all of the users in that group will have admin right? 19:20:55 <alexandrelevine_> Role - is a complex thing usually. And it is an extra thing. Unless we really need it I'd suggest we don't introduce it. 19:21:24 <sslypushenko> I don't see how things will be working without it 19:21:38 <alexandrelevine_> catherineD: Each Vendor will have two built-in Groups: Admins (now already), Users (later when needed). That's it. In the Group table we'll be adding users to those two groups. 19:21:44 <andrey-mp> it can be a two groups in the vendor records - admin group and user group... 19:21:45 <catherineD> alexandrelevine_: I absolutely think that we need it ... maybe not now but for sure in the future 19:21:47 <rockyg> Role tends to be a requirement that maps to an implementation, but most implementations implement roles via ACLs or other methods 19:21:54 <catherineD> sslypushenko: ++ 19:22:26 <alexandrelevine_> We will have implicit role differentiation. I'm against having explicit roles. 19:22:28 <sslypushenko> andrey-mp: We can not put roles in vendor table 19:22:34 <rockyg> groups is the way ACLs are done 19:22:42 <catherineD> alexandrelevine_: why would we want to do that? Let say in the future we want top add an other roles we will create an other user group? 19:22:50 <sslypushenko> because vendor can have more than one product 19:22:55 <rockyg> catherineD, Yup 19:23:03 <andrey-mp> btw, why we need regular users in the vendor object? 19:23:16 <rockyg> actually, another group, but not user. Some other name 19:23:25 <alexandrelevine_> catherineD: Because I don't want to predict whatever requirements might or might not fall on us some long time from now. We need to keep things very simple to move fast.. 19:23:41 <sslypushenko> All this idea looks like a try to hardcode some ACL's logic in datastucture 19:23:44 <catherineD> alexandrelevine_: andrey-mp: I did not see adding a role to the relationship would complicate the tasks.... in fact it helps 19:23:48 <alexandrelevine_> andrey-mp: It's in the requirements. There is a use-case. I'll tell you in a moment. 19:23:49 <sslypushenko> I'm totally against it 19:24:43 <catherineD> I really think that we should introduce role now ... 19:24:52 <alexandrelevine_> andrey-mp: The use-case Cloud Operator allows some of his private results or Clouds to be visible for some Users 19:24:58 <sslypushenko> catherineD: 100500+ ) 19:25:06 <catherineD> and let a policy file dictate the role privilege .. 19:25:43 <catherineD> alexandrelevine_: with a policy file ... you can add new role anytime .. no prediction needed .. 19:25:55 <sslypushenko> catherineD: we can introduce policily latter... but we need roles now 19:26:06 <alexandrelevine_> catherineD: In this case the model doesn't suite at all. Because where would you put those regular users? In the admin group? Why would you want the admin group in the vendor at all in this case? It's just a completely different story. 19:26:10 <catherineD> sslypushenko: agree 19:26:46 <catherineD> alexandrelevine_: we still agree with the model ... 19:27:11 <sslypushenko> alexandrelevine_: why we need to put regular users anywere? 19:27:17 <alexandrelevine_> catherineD: no, it doesn't work with the explicit roles. Role entity is not in the Domain model. 19:27:41 <alexandrelevine_> catherineD: And it'll have to be rethought quite a bit and I still don't understand the point now. 19:28:12 <catherineD> alexandrelevine_: the model assum all users that can create an entities are admins of that entities at this time 19:28:23 <alexandrelevine_> sslypushenko: Because they are regular users for some particular Vendor. They are allowed to read objects of such Vendor. No other regular users are allowed to. 19:28:38 <rockyg> alexandrelevine_, I think maybe an etherpad or doc walkthrough of how another "role" would be added via adding a group (or groups) might help with this discussion 19:28:47 <catherineD> alexandrelevine_: those regular user will have the role=USER 19:28:56 <alexandrelevine_> sslypushenko: See the use-case in question: 26 19:29:09 <sslypushenko> alexandrelevine_: Hmmm... So how public clouds will live in RefStack? 19:29:39 <alexandrelevine_> catherineD: Role for what? A user can be an Admin for a couple of Vendors and a regular user for the rest of the objects 19:30:14 <alexandrelevine_> Every User has basic rights. Users in Vendor Admin groups also have rights for those Vendors. 19:30:47 <rockyg> alexandrelevine_, an example of users and admins on a public cloud offering could help explain how you see this working. 19:30:48 <catherineD> Repeat question 26: Cloud Operator allows some of his private results or Clouds to be visible for some Users 19:30:52 <pvaneck> Is a vendor not just associated with one group id? 19:30:59 <rockyg> Maybe for next week? 19:31:18 <rockyg> Vendor could be associated with multiple groups. 19:31:32 <andrey-mp> pvaneck: right now we had such assumption ) 19:31:58 <catherineD> for question 26.... if a User wants to see private data of an Cloud Operator , that user should belong to the group of the Cloud_operator with role=USER 19:32:07 <rockyg> Vendor, vendor-product-admin, vendor-product-user, vendor-admin, vendor-product2-user, etc 19:32:23 <alexandrelevine_> pvaneck: Vendor is associated with one Group ID. User can be in many groups. 19:32:44 <andrey-mp> rockyg: what case of association vendor with many groups? 19:33:07 <alexandrelevine_> andrey-mp: There is no such case 19:33:08 <sslypushenko> alexandrelevine_: So how we will give admin privileges? 19:33:34 <sslypushenko> record in product table? 19:33:37 <alexandrelevine_> sslypushenko: Users registered in particular built-in admin Vendor group will have admin priviliges for this vendor. 19:33:42 <andrey-mp> i thought that all users in the group linked with vendor are admins of this vendor 19:33:50 <pvaneck> with just one group per vendor, then group roles should facilitate the different permission levels needed by these use cases 19:34:00 <rockyg> Unless all vendor associated groups (users, admins, plus all product options) are under one group id, vendor has to own multiple groups 19:34:02 <catherineD> andrey-mp: that is the initial implementation ... 19:34:15 <catherineD> pvaneck: ++ 19:34:46 <sslypushenko> alexandrelevine_: It will be better to have product admin group instead on vendor admin... 19:34:53 <catherineD> alexandrelevine_: I have a feeling that the term USER means different thing for you and for me sslypushenko: and pvaneck: 19:34:57 <sslypushenko> I think I manage to get your point 19:35:02 <rockyg> so, either multiple vendor owned groups, or single vendor group with roles. Two ways to implement 19:35:45 <alexandrelevine_> One Vendor - One Group. Users in this Group are admins of the Vendor. 19:36:04 <catherineD> sslypushenko: this is the point that alexandrelevine_: had discussed ... a group should be associated to a product too ... but it will be the next implementation 19:36:11 <sslypushenko> alexandrelevine_: Hmm... but what about private test result? 19:36:46 <catherineD> alexandrelevine_: One vendor , one group, Users in this group can be admin or read only user ... 19:37:04 <catherineD> read only user can view private results of that vendor 19:37:26 <catherineD> and that is implemented by introducing role of user in that group ... 19:37:32 <pvaneck> I feel like we just need a toggle for if a user is admin or non-admin in a specific group if you want some users to only have read-only access 19:38:18 <catherineD> pvaneck: yup that is fine by we need role ... admin and non-admin 19:38:52 <catherineD> so my vote is to keep the role column in the user-group relationship table ... 19:38:56 <sslypushenko> catherineD: +1 19:39:28 <catherineD> should we vote? 19:39:35 <sslypushenko> at least 2 rooles 19:39:40 <catherineD> yup 19:39:41 <rockyg> Could keep it in and if i looks like it adds no value, it can be removed later? 19:39:44 <alexandrelevine_> I'm sorry. I have an urgent call now. 19:39:55 <catherineD> alexandrelevine_: ok np 19:40:18 <catherineD> we can just discuss the next item and will make decision with your present .. 19:40:34 <andrey-mp> lets move to next ) 19:41:04 <catherineD> #agree we will vote on having a role column in the user-group relationship table later 19:41:41 <catherineD> #agreed we will vote on having a ROLE column in the usdr-group relationship table later 19:42:05 <catherineD> #topic Auditability implementation for RefStack? Do we need the "updated" columns? 19:42:42 <catherineD> please see comments on line 126 of https://review.openstack.org/#/c/268922/ 19:43:33 <catherineD> I know this is not perfect .. but with the updated column .. at least we know who is updating the record last ... 19:43:49 <sslypushenko> I don't get a point of this field 19:43:51 <catherineD> preferly audit should be done by database log ... 19:44:07 <andrey-mp> i think that if we need logging that it is better to create 'add-only' table with all records. 19:44:44 <andrey-mp> is database can help? it contains operations from only one user - refstack site 19:44:51 <sslypushenko> If we want to have some logging we should do it in some other way 19:44:58 <catherineD> sslypushenko: let say someone changes the role from user to admin ... the user who makes the update will be loggoed 19:45:34 <catherineD> sslypushenko: agree ... but in the interim .... is there something we can do? 19:45:40 <sslypushenko> but do we need such kind of logging 19:45:54 <sslypushenko> ? 19:46:11 <andrey-mp> i mean that all operations with refstack db is done by refstack site that means 'refstack' user. 19:46:14 <rockyg> does the DB have that function as part of the config? 19:46:26 <catherineD> sslypushenko: see line 163 of https://review.openstack.org/#/c/226902/ 19:46:46 <catherineD> rockyg: db will have the log ... but we need log analysis tools ... 19:46:47 <andrey-mp> may be it is better to implement 'add-only' logging table later? 19:47:22 <catherineD> andrey-mp: would that e an additional table? 19:47:29 <andrey-mp> yes 19:48:12 <rockyg> catherineD, if we've got the logging, then the analysis should be outside the db. 19:48:33 <catherineD> we can remove the updated column (which is not perfect for auditting ) we jsut need to communicate to DefCore that auditting will be implemanted later .. 19:48:34 <rockyg> Although last change would at least give a starting point on where to look in logs. 19:48:48 <andrey-mp> table that doesn't linked with the system but contains all (or specific) write operations. and later some can analyse this table for information... 19:49:02 <catherineD> andrey-mp: ++ 19:49:30 <sslypushenko> andrey-mp: That is sounds good 19:49:44 <catherineD> rockyg: hogepodge: DefCore should be OK with us not implementing auditting at the initial phase? 19:49:44 <andrey-mp> :) 19:50:15 <catherineD> so do we all agree that we do not need the updated columns? 19:50:26 <hogepodge> catherineD: I think so 19:51:03 <catherineD> sslypushenko: pvaneck: rockyg: your thoughts? I know andrey-mp: wants to have it removed .. 19:51:47 <rockyg> works for me. As long as logging is there, we have the info. Just not great access. 19:51:51 <pvaneck> Yea, i think an eventual audit_log table would be best 19:51:55 <sslypushenko> catherineD: It looks like it is early for now 19:52:05 <sslypushenko> pvaneck: +1 19:52:55 <catherineD> #agreed Autting function will be implemented later. Remove the "updated" related columns in all tables. 19:53:11 <catherineD> #topic Do we need the "deleted" columns? 19:53:45 <sslypushenko> yeap 19:53:46 <catherineD> pls see comment line 138 https://review.openstack.org/#/c/268922/ 19:53:59 <sslypushenko> I think we need soft delete 19:54:29 <sslypushenko> it is part of functionality of oslo-db 19:54:32 <catherineD> just a time check ...we only have 6 mins to go ... could we continue our discussion at #refstack after this ... 19:54:42 <sslypushenko> +1 19:54:47 <andrey-mp> yes 19:55:08 <catherineD> we have the momentum going so I really like us to continue discussion ..... 19:55:13 <catherineD> thank you 19:55:40 <catherineD> sslypushenko: so I have not seen RefStack using the delete column in the existing tables... 19:55:54 <sslypushenko> that is right 19:56:31 <catherineD> but I guess if that is part of oslo-db ... then we may want to keep it 19:56:36 <sslypushenko> but I think we need it... it is kind of openstack way) 19:57:22 <catherineD> alright ... but before our final decision let review the next topic ... because it is related ... we will come back to this item in a bit 19:57:36 <andrey-mp> we can leave these two columns and use them later ) 19:57:36 <catherineD> #topic Do we want to enforce organization/product name to be unique? 19:57:49 <catherineD> andrey-mp: + 19:59:09 <catherineD> That means that the name will be unique based on spelling only not upper/lower case ... so Private Cloud and PRIVATE CLOUD are the same name for us ... 19:59:25 <catherineD> let move to #refstack ... 19:59:30 <sslypushenko> + 19:59:34 <andrey-mp> I don't have strong desicion on this but my thoughts that we don't need it 19:59:40 <andrey-mp> moving... 19:59:41 <catherineD> #endmeeting