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