| *** davidlenwell has quit IRC | 01:05 | |
| *** davidlenwell has joined #refstack | 01:07 | |
| *** ChanServ sets mode: +o davidlenwell | 01:07 | |
| *** markvoelker_ has quit IRC | 02:26 | |
| *** coolsvap|away is now known as coolsvap | 05:11 | |
| *** coolsvap is now known as coolsvap|away | 07:18 | |
| openstackgerrit | David Liu proposed openstack/refstack-client: Remove RefStack dependency on Keystone client. https://review.openstack.org/265747 | 08:05 |
|---|---|---|
| openstackgerrit | Catherine Diep proposed openstack/refstack: Add database tables to support vendor/product registration. https://review.openstack.org/268922 | 08:25 |
| openstackgerrit | Andrey Pavlov proposed openstack/refstack: Create group table. https://review.openstack.org/268929 | 08:52 |
| openstackgerrit | Andrey Pavlov proposed openstack/refstack: Create group table. https://review.openstack.org/268929 | 11:38 |
| openstackgerrit | David Liu proposed openstack/refstack-client: Remove RefStack dependency on Keystone client. https://review.openstack.org/265747 | 11:46 |
| *** edmondsw has joined #refstack | 13:12 | |
| *** edmondsw has quit IRC | 14:02 | |
| openstackgerrit | Andrey Pavlov proposed openstack/refstack: Introduce organization and product tables https://review.openstack.org/269066 | 14:05 |
| openstackgerrit | Andrey Pavlov proposed openstack/refstack: Introduce organization and product tables https://review.openstack.org/269066 | 14:59 |
| *** resker has quit IRC | 15:53 | |
| *** edmondsw has joined #refstack | 16:16 | |
| -openstackstatus- NOTICE: Gerrit is restarting quickly as a workaround for performance degradation | 16:50 | |
| openstackgerrit | Catherine Diep proposed openstack/refstack: This specification proposes RefStack to add user group support. https://review.openstack.org/269184 | 16:55 |
| *** hockeynut_afk has joined #refstack | 17:10 | |
| *** davidlenwell has quit IRC | 18:22 | |
| *** davidlenwell has joined #refstack | 18:24 | |
| *** ChanServ sets mode: +o davidlenwell | 18:24 | |
| *** alexandrelevine has joined #refstack | 18:38 | |
| *** hockeynut_afk is now known as hockeynut | 18:43 | |
| *** pvaneck has joined #refstack | 18:57 | |
| *** alexandrelevine has quit IRC | 19:14 | |
| *** andrey-mp_ has joined #refstack | 19:55 | |
| catherineD | Hi everyone, | 20:00 |
| sslypushenko | + | 20:00 |
| catherineD | I am so excited that we finally get this going ... | 20:00 |
| sslypushenko | me too | 20:00 |
| andrey-mp_ | about unique names - I don't have strong desicion on this but my thoughts that we don't need it | 20:01 |
| pvaneck | dont think we need to enforce uniqueness for now. maybe just for orgs if at all | 20:01 |
| andrey-mp_ | because user can enter 'private cloud' and 'private cloud.'. or add/remove space in name... | 20:01 |
| sslypushenko | I think we can do this enforcement | 20:01 |
| catherineD | if we enforce uniqueness and with soft delete , since the record are never deleted ... a name that is used will never be used again even that it is deleted (from soft delete) | 20:02 |
| sslypushenko | hmmm that is right | 20:02 |
| catherineD | because for soft delete the different between delete or not is a flag in the deleted column | 20:03 |
| sslypushenko | but it can be avoid it some how | 20:03 |
| sslypushenko | with some more complex constraints | 20:04 |
| andrey-mp_ | another thought - foundation admin may register vendors/products after small check and suggest to rename... | 20:04 |
| sslypushenko | but I see some other issue here | 20:04 |
| andrey-mp_ | but we can't block renaming after approvement | 20:05 |
| sslypushenko | someone can create vendors records with good known trademarks | 20:05 |
| catherineD | andrey-mp_: I think foundation should register vendors but not product ... vendor admin should register product ... this is an other discussion topic | 20:05 |
| andrey-mp_ | catherineD: yes, I agree | 20:06 |
| catherineD | sslypushenko: could you explain some more? | 20:06 |
| andrey-mp_ | i mean that user can create vendor with any name but foundation admin will approve only if the vendor has correct name (and other properties) | 20:07 |
| sslypushenko | just thoughts... If foundation handles vendor registration, so that if should work fine | 20:07 |
| andrey-mp_ | so it is task for foundation admin - checking name of the vendor | 20:07 |
| *** alexandrelevine has joined #refstack | 20:08 | |
| sslypushenko | so we can enforce unique vendor name | 20:08 |
| alexandrelevine | OI | 20:08 |
| alexandrelevine | I'm back. Am I too late? | 20:08 |
| catherineD | so foundation should check and enforce for uniqueness of name? | 20:08 |
| sslypushenko | and unique pair vendor/product | 20:08 |
| alexandrelevine | Sorry about the call. Couldn't help it. | 20:08 |
| alexandrelevine | did we decide about the Groups and Roles if I may ask? | 20:09 |
| catherineD | alexandrelevine: no we are on topic 2.3.4 of the agenda | 20:09 |
| andrey-mp_ | catherineD: foundation should check for correctness | 20:09 |
| catherineD | alexandrelevine: no we have not ... we waite for you | 20:09 |
| alexandrelevine | catherineD: Thank you :) | 20:09 |
| catherineD | let's get the uniqness topic settle then we can revisit the group / user | 20:10 |
| alexandrelevine | sure | 20:11 |
| sslypushenko | catherineD: unique vendor, unique vendor+product | 20:11 |
| catherineD | andrey-mp_: checking should include upper/lower case ... that is very tedious .. | 20:11 |
| andrey-mp_ | catherineD: not only. also spaces, dots or other punctuation symbols | 20:12 |
| catherineD | andrey-mp_: agree ... so it is very tedious ... | 20:13 |
| alexandrelevine | catherineD: We should ask maybe the DefCore guys - would they allow renaming, for example? | 20:13 |
| catherineD | alexandrelevine: OK good idea .. so we will ask DefCore ... | 20:14 |
| andrey-mp_ | and another thought - we will not have many vendors... | 20:14 |
| catherineD | so we still want to add the delete column right? | 20:14 |
| sslypushenko | I think so... | 20:14 |
| andrey-mp_ | if it is a oslo (or Openstack way) then we want | 20:15 |
| catherineD | do we care for uniqueness in product? | 20:15 |
| alexandrelevine | Same thing - ask DefCore. Uniqueness, Renaming, allowed characters..... | 20:15 |
| catherineD | #agreed All tables should include the "delete" related column | 20:16 |
| sslypushenko | +1 | 20:16 |
| alexandrelevine | none of cares to be honest :) | 20:16 |
| andrey-mp_ | catherineD: i think no. vendor will mantain their products easily with it | 20:16 |
| catherineD | #agreed RefStack will check with DefCore/Foundation whether vendor name can be renamed | 20:16 |
| sslypushenko | andrey-mp_: I would suggest to keep vendor+product unique | 20:16 |
| catherineD | sslypushenko: how can we do that? | 20:17 |
| andrey-mp_ | sslypushenko: it is a good idea but how we can do it at DB level? ) | 20:17 |
| alexandrelevine | We don't do it at DB level. | 20:17 |
| sslypushenko | DB supports complex unique constraints | 20:17 |
| alexandrelevine | We apply constraints in the business logic. | 20:18 |
| andrey-mp_ | but it will slow DB operations | 20:18 |
| catherineD | sslypushenko: the issue is the name will be mix cases ... | 20:18 |
| alexandrelevine | At least if we want to have DB as simple and upgradeable as possible. | 20:18 |
| catherineD | Amazon and AMAZON are 2 names | 20:18 |
| sslypushenko | yeap... but we will do some kind of calidation befor put data in to dv | 20:18 |
| alexandrelevine | I suggest leaving DB to store our stuff and not do any checking at all. | 20:18 |
| sslypushenko | *db | 20:19 |
| catherineD | yup that is why I did the upper of name in the table ... | 20:19 |
| sslypushenko | alexandrelevine: I don't agree with you | 20:19 |
| catherineD | with that we are not sensitive to the cases and then we can use DB to contrain the name | 20:19 |
| andrey-mp_ | sslypushenko: if foundation will not approve two same vendors then we don't face with this problem | 20:19 |
| *** alexandrelevine_ has joined #refstack | 20:20 | |
| sslypushenko | andrey-mp_: My point of view here that we should keep uniqueness not only for vendors but also for vendors and products | 20:21 |
| alexandrelevine_ | catherineD: I missed the answer: why did you add the Upper Name in the DB? | 20:21 |
| sslypushenko | and also I think that as much as possible kind of such related with data model should be placed in db | 20:22 |
| catherineD | alexandrelevine_: so that AmaZon and AmAzon is one name AMAZON for us ... with this we can use db to contrain on name uniqueness .. | 20:22 |
| catherineD | sslypushenko: ++| | 20:22 |
| andrey-mp_ | sslypushenko: i agree with this - but if vendors will unique then vendor can manage their products with uniquness.... | 20:22 |
| catherineD | andrey-mp_: I am just afraid that people make typo.. | 20:23 |
| *** alexandrelevine has quit IRC | 20:23 | |
| sslypushenko | andrey-mp_: Vendor can but not must... I think Vendor must manage products with uniquness | 20:23 |
| *** alexandrelevine has joined #refstack | 20:23 | |
| alexandrelevine | I get disconnected all the time by some weird reason. | 20:24 |
| sslypushenko | alexandrelevine: It is IRC))) | 20:24 |
| catherineD | alexandrelevine: hmm that is not good | 20:24 |
| andrey-mp_ | catherineD: then they can rename any item :) | 20:24 |
| alexandrelevine | catherineD: I strongly disagree with such pattern, to be honest. Let's not burden DB with additional data which we can check ourselves. | 20:24 |
| sslypushenko | alexandrelevine: It will be really big issue | 20:25 |
| catherineD | alexandrelevine: DB is the best place for these tasks for performance reason | 20:25 |
| alexandrelevine | catherineD: We don't have any performance issues yet | 20:25 |
| *** alexandrelevine_ has quit IRC | 20:25 | |
| alexandrelevine | catherineD: And we won't until we see some coming. I don't see any. | 20:25 |
| sslypushenko | I don't see the way how to check uniqueness of item in db | 20:25 |
| catherineD | alexandrelevine: I know I am just a performance engineer that always design for that :-) | 20:25 |
| alexandrelevine | catherineD: In order to talk about performance we first need to get Non-Functional requirements from the DefCore or make them approve ours. | 20:26 |
| catherineD | sslypushenko: by defining UNI | 20:26 |
| sslypushenko | catherineD: yeap if we use DB | 20:26 |
| alexandrelevine | catherineD: Some well-known person said once: Preliminary optimization is a root of all evils. Not that I completely agree with it though | 20:26 |
| sslypushenko | but alexandrelevine suggest to do it in code | 20:27 |
| catherineD | sslypushenko: yup otherwais we may need to dump all record an manipulated in the application | 20:27 |
| alexandrelevine | catherineD: But in our case it's definitely not a performance issue and not a way to solve it. | 20:27 |
| sslypushenko | alexandrelevine: Sorry, but I disagree with you | 20:27 |
| alexandrelevine | Guys, I suggest to start worrying about it when we have something to worry on. I don't at the moment. And I don't see it coming at all. Not even close. | 20:27 |
| catherineD | ok let me suggest this ,,, for name uniqueness let us check qieh DefCore. .. then we can continue the discussion | 20:28 |
| sslypushenko | We can already fill some slowdown in current RefStack | 20:28 |
| sslypushenko | catherineD: + | 20:28 |
| alexandrelevine | sslypushenko: With what exactly? That we shouldn't to preliminary performance optimizations? | 20:28 |
| catherineD | sslypushenko: ++ | 20:28 |
| alexandrelevine | "do" not "to" | 20:28 |
| catherineD | Let move on ... | 20:28 |
| sslypushenko | alexandrelevine: Agreed with keeping thing as much as possible | 20:29 |
| alexandrelevine | sslypushenko: If we do have slowdown let's profile it and find a solution for particular problem. Not imaginary one. | 20:29 |
| catherineD | the different in these two specs are one with a table "group" define and one without https://review.openstack.org/#/c/268922/ and https://review.openstack.org/#/c/269184/ | 20:29 |
| sslypushenko | alexandrelevine: yeap you are right) | 20:30 |
| catherineD | alexandrelevine: since you mention that we will never do group management that is why I think we may not need the group table | 20:30 |
| catherineD | do we need the group table ? | 20:30 |
| alexandrelevine | I like the group approach better. | 20:31 |
| alexandrelevine | catherineD: Where would you store lists of users for built-in groups? | 20:31 |
| sslypushenko | agreed with alexandrelevine | 20:31 |
| alexandrelevine | I still don't see why we need the second group-user-role table. | 20:31 |
| catherineD | the group table would introduce an other level of reference ... the relationship will store in org-user table | 20:32 |
| sslypushenko | group is much general entity | 20:32 |
| catherineD | so we agree to go the group route? | 20:32 |
| catherineD | sslypushenko: I agreed that is my initial thinking too ... | 20:32 |
| catherineD | #agreed RefStack will create a group table | 20:33 |
| catherineD | back to the user-group-role discussion | 20:33 |
| catherineD | alexandrelevine: we do not add a second group-user-role table ... | 20:33 |
| alexandrelevine | org-user table is exactly the group table if we remove the role. I think group is more straightforward naming. | 20:34 |
| catherineD | we replace the group-user table with group-user-role table | 20:34 |
| catherineD | alexandrelevine: we already agree that we will not use org-user table | 20:34 |
| sslypushenko | group-user-role table should work fine | 20:34 |
| catherineD | we are now revisit the role discussion | 20:34 |
| alexandrelevine | catherineD: Ok, in my Domain Model there is a link between Organization and Group. It's named "group of admins". | 20:35 |
| alexandrelevine | catherineD: You can't put any roles in there unless we change the Domain Model. | 20:35 |
| alexandrelevine | catherineD: And having a role in the Group entity is really bad. It's not for Groups to have such notions usually. | 20:36 |
| catherineD | alexandrelevine: in my mind group of admin is a group of user with admin role | 20:36 |
| catherineD | still fit your model | 20:36 |
| alexandrelevine | catherineD: Correct. But no "role" field there. | 20:36 |
| alexandrelevine | catherineD: Just a Group of Users. | 20:37 |
| catherineD | alexandrelevine: object model does not dictate the implementation details right? | 20:37 |
| sslypushenko | alexandrelevine: I think it is enough to mention that user can have different rights in group | 20:37 |
| alexandrelevine | catherineD: It does to some extent. | 20:37 |
| catherineD | as long as the implementation implements whatever dictated in the model | 20:37 |
| alexandrelevine | sslypushenko: Usually it's not enough and usually it's not done this way. Roles are a more complex and separate entity from the Groups. | 20:38 |
| *** markvoelker has joined #refstack | 20:38 | |
| alexandrelevine | catherineD: Implementation usually doesn't implement something which is not in the design model :) If we need to implement it, it has to be reflected in the design. | 20:39 |
| sslypushenko | alexandrelevine: yes... So I suggest to not put it in current model, just mention what users with different roles can do | 20:39 |
| catherineD | sslypushenko: ++ | 20:39 |
| alexandrelevine | sslypushenko: What do you mean mention? Mention how and where? | 20:39 |
| sslypushenko | Right now we see schema for admin role | 20:39 |
| alexandrelevine | I | 20:40 |
| sslypushenko | just put relations for regular user in other color on same schema | 20:40 |
| alexandrelevine | Where? | 20:40 |
| alexandrelevine | In the Domain model picture? | 20:40 |
| sslypushenko | hmm... give a sec.... | 20:41 |
| catherineD | alexandrelevine: I see that the object model is the relationship of objects ... it does not necessary dictates all the use cases .. | 20:41 |
| alexandrelevine | catherineD: It implements the use-cases. | 20:42 |
| catherineD | I think the best solution for us right now is to vote on this | 20:42 |
| alexandrelevine | catherineD: The ones not implemented by the object model are commented below - it's written why they are skipped and how it is suggested for them to be added later. Like in secition Vendor Users and Vendor Product Admins | 20:42 |
| alexandrelevine | "section" | 20:42 |
| sslypushenko | because we don't have of relations in Domain model now... we can just live it as it is... And describe role policies in words | 20:42 |
| sslypushenko | *have all relations | 20:43 |
| alexandrelevine | sslypushenko: Please take a look at Vendor Users and Vendor Product Admins section | 20:43 |
| sslypushenko | I'm there | 20:43 |
| alexandrelevine | sslypushenko: It's explained how I suggest to implement these two use-cases. No explicit roles required. | 20:44 |
| sslypushenko | required yeat | 20:44 |
| alexandrelevine | sslypushenko: How? | 20:45 |
| alexandrelevine | sslypushenko: Which use-case is not covered? | 20:45 |
| sslypushenko | We should not put ACL in to data model | 20:45 |
| catherineD | I have a hard stop in 15 mins .... we have 3 more items to discuss ... could we ether agree based on vote or revisit this topic ? | 20:46 |
| sslypushenko | alexandrelevine: I'm not so good to see in future) But anyway if roles are not useful for now it do not mean anything | 20:46 |
| *** alexandrelevine_ has joined #refstack | 20:46 | |
| alexandrelevine_ | Sorry. Got kicked out again. | 20:46 |
| alexandrelevine_ | sslypushenko: Could you repeat, which use-case is not covered? | 20:46 |
| catherineD | sslypushenko: let's revisit this later ... | 20:47 |
| pvaneck | when you say add a "Group of Users" to vendor, how is the association modeled in the db? | 20:47 |
| sslypushenko | catherineD: Lets maybe schedule one more meeting for discussion especially this question. We definitely need to get a point which will work of all of us | 20:48 |
| catherineD | sslypushenko: good idea ... | 20:48 |
| alexandrelevine_ | pvaneck: The review provided by Andrey showed it. Just a Group ID in the Orgranization | 20:48 |
| sslypushenko | voting is not an option here | 20:48 |
| alexandrelevine_ | sslypushenko: I suggest moving down from the use-cases, not from implementation up. | 20:49 |
| alexandrelevine_ | catherineD: Tomorrow? | 20:49 |
| sslypushenko | tommorrow will work for me | 20:49 |
| catherineD | I will schedule an other meeting and at that time if we do not agree .. we will go by vote | 20:49 |
| catherineD | what time tomorrow? | 20:49 |
| *** alexandrelevine has quit IRC | 20:50 | |
| catherineD | same time as today? | 20:50 |
| alexandrelevine_ | whatever you say | 20:50 |
| sslypushenko | same as today's meeting | 20:50 |
| alexandrelevine_ | The earlier the better for me. | 20:50 |
| pvaneck | isnt that group id the the group of admins for that org? | 20:50 |
| catherineD | so our meeting is 19UTC today | 20:50 |
| alexandrelevine_ | pvaneck: Yes | 20:50 |
| catherineD | so should we meet 18 UTC or 19 UTC tomorrow? | 20:51 |
| sslypushenko | same as today will work for me | 20:51 |
| alexandrelevine_ | I vote for 18 UTC | 20:51 |
| alexandrelevine_ | But can do 19 as well | 20:51 |
| sslypushenko | 18.30?)) | 20:51 |
| catherineD | ok deal 18L30 | 20:52 |
| alexandrelevine_ | whatever :) | 20:52 |
| catherineD | 18:30 | 20:52 |
| alexandrelevine_ | cool | 20:52 |
| sslypushenko | great | 20:52 |
| catherineD | I will send a meeting notice ... | 20:52 |
| catherineD | thank you so much .... | 20:52 |
| alexandrelevine_ | thanks. | 20:52 |
| alexandrelevine_ | bye | 20:52 |
| sslypushenko | Need to run now, so see you tommor | 20:52 |
| *** alexandrelevine_ has quit IRC | 20:52 | |
| catherineD | we have disagreement but that is for the health of the project | 20:52 |
| catherineD | I really appreciate your effort!!! | 20:53 |
| catherineD | bye | 20:53 |
| andrey-mp_ | bye | 20:56 |
| *** andrey-mp_ has quit IRC | 20:56 | |
| *** edmondsw has quit IRC | 22:02 | |
| *** pvaneck has quit IRC | 22:36 | |
| *** davidlenwell has quit IRC | 23:38 | |
| *** davidlenwell has joined #refstack | 23:58 | |
| *** ChanServ sets mode: +o davidlenwell | 23:58 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!