| *** markvoelker has quit IRC | 01:14 | |
| *** markvoelker has joined #refstack | 02:52 | |
| *** markvoelker_ has joined #refstack | 02:56 | |
| *** markvoelker has quit IRC | 03:00 | |
| *** markvoelker_ has quit IRC | 03:01 | |
| *** markvoelker has joined #refstack | 03:06 | |
| *** Deng has joined #refstack | 03:40 | |
| Deng | hi everyone | 03:40 |
|---|---|---|
| Deng | can I raise question here? | 03:41 |
| *** markvoelker has quit IRC | 04:39 | |
| *** markvoelker has joined #refstack | 04:40 | |
| *** markvoelker_ has joined #refstack | 07:11 | |
| *** markvoelker has quit IRC | 07:15 | |
| *** markvoelker_ has quit IRC | 07:57 | |
| *** markvoelker has joined #refstack | 08:38 | |
| *** markvoelker has quit IRC | 08:43 | |
| *** markvoelker has joined #refstack | 08:46 | |
| openstackgerrit | David Liu proposed openstack/refstack-client: Remove RefStack dependency on Keystone client. https://review.openstack.org/265747 | 08:46 |
| *** markvoelker has quit IRC | 09:02 | |
| *** markvoelker has joined #refstack | 09:19 | |
| *** markvoelker has quit IRC | 09:24 | |
| *** markvoelker has joined #refstack | 09:40 | |
| *** markvoelker has quit IRC | 09:45 | |
| *** markvoelker has joined #refstack | 10:16 | |
| *** markvoelker has quit IRC | 10:21 | |
| *** markvoelker has joined #refstack | 10:44 | |
| *** markvoelker has quit IRC | 10:49 | |
| *** markvoelker has joined #refstack | 11:14 | |
| *** markvoelker has quit IRC | 11:20 | |
| *** markvoelker has joined #refstack | 11:32 | |
| *** markvoelker has quit IRC | 11:36 | |
| *** markvoelker has joined #refstack | 12:11 | |
| *** markvoelker has quit IRC | 12:16 | |
| *** Deng has quit IRC | 12:23 | |
| *** markvoelker has joined #refstack | 12:49 | |
| *** markvoelker has quit IRC | 12:54 | |
| *** markvoelker has joined #refstack | 13:10 | |
| *** markvoelker has quit IRC | 13:15 | |
| *** edmondsw has joined #refstack | 13:30 | |
| *** markvoelker has joined #refstack | 13:52 | |
| *** markvoelker has quit IRC | 13:57 | |
| *** markvoelker has joined #refstack | 14:00 | |
| *** markvoelker_ has joined #refstack | 14:01 | |
| *** markvoelker has quit IRC | 14:05 | |
| *** markvoelker_ has quit IRC | 15:51 | |
| *** johnny___ has joined #refstack | 16:33 | |
| *** johnny___ has left #refstack | 16:34 | |
| *** markvoelker has joined #refstack | 16:36 | |
| *** bobby__ has joined #refstack | 16:36 | |
| *** bobby__ has quit IRC | 17:04 | |
| *** catherineD has quit IRC | 17:13 | |
| *** bobby__ has joined #refstack | 17:14 | |
| *** bobby__ has quit IRC | 17:18 | |
| *** andrey-mp has joined #refstack | 18:06 | |
| *** catherineD has joined #refstack | 18:27 | |
| *** alexandrelevine has joined #refstack | 18:30 | |
| catherineD | Hello | 18:31 |
| alexandrelevine | Hi | 18:31 |
| andrey-mp | hello | 18:31 |
| catherineD | Hi .. Let's wait a little bit for Sergey and Paul | 18:32 |
| catherineD | are you both at the same time zone? | 18:32 |
| catherineD | I mean alexandrelevine: and andrey-mp: | 18:32 |
| alexandrelevine | yes | 18:33 |
| catherineD | that is great ... so I put the item that we need to discuss at the bottom of https://etherpad.openstack.org/p/refstack-meeting-16-01-18 | 18:34 |
| *** tpeoples has quit IRC | 18:34 | |
| *** pvaneck has joined #refstack | 18:34 | |
| *** sslypushenko has quit IRC | 18:35 | |
| pvaneck | o/ | 18:35 |
| *** hockeynut has quit IRC | 18:36 | |
| *** tpeoples has joined #refstack | 18:36 | |
| *** sslypushenko has joined #refstack | 18:36 | |
| catherineD | pls find item for discussion at the botton of https://etherpad.openstack.org/p/refstack-meeting-16-01-18 | 18:36 |
| *** hockeynut has joined #refstack | 18:36 | |
| catherineD | sslypushenko: ping .. | 18:37 |
| alexandrelevine | Can I start if everybody is ready? | 18:37 |
| sslypushenko | pong) | 18:37 |
| catherineD | :-) | 18:37 |
| sslypushenko | Lets roll) | 18:38 |
| alexandrelevine | Please hear my argumentation first. I'll tell when I'm finished, ok? | 18:38 |
| catherineD | alexandrelevine: go ahead | 18:38 |
| sslypushenko | alexandrelevine: Sure | 18:38 |
| alexandrelevine | 1. The use-case requiring role User (non-Admin) is marginal and prospective. It might never come to it. Or at some distant point. Here is where it comes from (Mark's spec): | 18:39 |
| alexandrelevine | Improve ScaleIO presence in OpenStack. Drive it to become a real competitor for Ceph in OpenStack. Attach file… drag files or paste image (⌘ V) | 18:39 |
| alexandrelevine | Sorry :) | 18:39 |
| alexandrelevine | That's a wrong copy-paste. | 18:39 |
| alexandrelevine | Further capabilities could conceivably be useful and should be kept in mind when designing the code in order to minimize rework if they're ever desired in the future, but are out of scope for this spec. | 18:39 |
| alexandrelevine | 2. I usually try to design the minimal set which is extentable to where we want to go. No further entities or properties to appear until they are really proven to be needed. | 18:40 |
| alexandrelevine | That's why Role is not exactly needed for our current situation and for some long time, keeping in mind speed of RefStack development so far. | 18:40 |
| alexandrelevine | 3. The suggested model relies on generic Groups of Users which are associated with Organization (one to one) providing a Group of Admins. | 18:41 |
| alexandrelevine | 4. When we come to this. The model can be enhanced to accommodate regular users per Vendor by adding another built-in Users Group to Organization. No problems with DB or upgrade. | 18:42 |
| alexandrelevine | 5. Alternative model can exist as suggested by Catherine where we don't have generic Groups but rather have Organization_Users table where each User has a Role. | 18:42 |
| alexandrelevine | I don't like this model for two reasons: | 18:42 |
| alexandrelevine | a) It leaves us with an unused rudiment for a long time | 18:43 |
| alexandrelevine | b) It leaves us without generic and common solution for groups-users-companies which is proven to be very extendable and easy to understand and manage. | 18:43 |
| alexandrelevine | I'm not against it completely, though but I don't see why we need this additional complications now. We | 18:44 |
| alexandrelevine | We're spending lots of time just talking about this potential prospective marginal use-case when we have lots of things to do. | 18:44 |
| alexandrelevine | Finished. | 18:44 |
| sslypushenko | Pretty clear point of view! thx! | 18:45 |
| sslypushenko | But why do you think that generic users will be an rudiment? | 18:45 |
| catherineD | I suggest we response to alexandrelevine: 's one point of a time ... each of us will take the floor and mark finish as alexandrelevine: had done | 18:46 |
| alexandrelevine | It is now | 18:46 |
| catherineD | who want to have the floor for point 1 ? | 18:46 |
| sslypushenko | catherineD: ok.. Your turn) | 18:46 |
| alexandrelevine | Until this prospective use-case which might not come to being even by Mark's estimations will be needed, it's a rudiment. And there is a high probability when we come to this, the reqs for roles become completely different altogether - for example much more complex | 18:47 |
| catherineD | ok I will mark when I finish | 18:47 |
| catherineD | point 1 in Mark's https://review.openstack.org/#/c/226902/4/specs/proposed/vendor_result_validation.rst line 79 ... He remind us to keep in mind when designing the code 'in order to minimize rework' if they're ever desired in the future | 18:48 |
| catherineD | I know from my own experience that we need a read only role ... | 18:49 |
| catherineD | I know that Rocky in her company needed this feature ... | 18:49 |
| catherineD | as said, all I want to suggest now is that we add this ROLE column and set it to ADMIN.... I do not see that we keep a path for us to have an easy upgrade in the future. | 18:50 |
| catherineD | done for point 1 .... sslypushenko: you will be next on this point? | 18:51 |
| alexandrelevine | Hold on. | 18:51 |
| alexandrelevine | Let me reply. | 18:51 |
| sslypushenko | alexandrelevine: yes | 18:51 |
| catherineD | alexandrelevine: go ahead | 18:52 |
| sslypushenko | I just have +1 for catherineD's responce | 18:52 |
| alexandrelevine | It's actually easy. Requirements aren't determined by us. I don't invent them. I rely on them. Mark has supposedly collected them even from Rocky. | 18:52 |
| alexandrelevine | If he says that this is a "potential" requirement for the future then it is. | 18:52 |
| alexandrelevine | If we don't believe him let's bring this up and ask Rocky or whoever. If they make this a first-class use-case for now I'll redesign right away. | 18:53 |
| alexandrelevine | Requirements tend to change drastically - all of you know that. | 18:53 |
| alexandrelevine | Let's not rely on having this one staying unchanged for another year. | 18:53 |
| alexandrelevine | And my suggested solution doesn't prohibit it - I explained the way to accommodate it any time. | 18:54 |
| alexandrelevine | Finished. | 18:54 |
| catherineD | great system in marking finished :-) who want to go next? | 18:55 |
| catherineD | we are still on point 1 | 18:55 |
| sslypushenko | hmmm | 18:55 |
| pvaneck | I think just proceed without explicit roles for now since we'll be giving everyone admin roles to begin with if we do have roles. | 18:56 |
| pvaneck | Implicit admin roles given by the org group is enough for now. | 18:56 |
| pvaneck | I don't think read-only access is a big deal for the time being with everything else not currently implemented. | 18:56 |
| pvaneck | Adding a role column or a user_group column are both straightforward future additions. | 18:56 |
| sslypushenko | I don't see a big point to discuss here... alexandrelevine do you agree that we can leave with single role for now? | 18:56 |
| alexandrelevine | pvaneck: exactly | 18:56 |
| alexandrelevine | sslypushenko: I agree as long as we don't have the word Role anywhere, including DB :) | 18:57 |
| sslypushenko | Because it looks like we stuck on things which is just a matter of taste | 18:58 |
| catherineD | I suggest we vote ... | 18:58 |
| alexandrelevine | sslypushenko: Close to this but not quite. :) | 18:58 |
| sslypushenko | catherineD: please no) | 18:58 |
| catherineD | to keep a column in the user-group relationship table ... | 18:58 |
| catherineD | sslypushenko: so do not vote? | 18:59 |
| sslypushenko | we should all get agreed on same point | 18:59 |
| catherineD | if it is a matter of taste and style then people are different ... | 18:59 |
| sslypushenko | it will not work if we force part of us to some point of view | 18:59 |
| sslypushenko | I think we can leave with alexandrelevine suggestion if his suggestion will work for us | 19:00 |
| catherineD | we always do some of us have to give ... because we are differnet and that is the values of a diverse team .. | 19:00 |
| sslypushenko | I think it can work for me | 19:00 |
| sslypushenko | catherineD: Do you have any strict objections here? | 19:01 |
| catherineD | so I see that pvaneck: sslypushenko: alexandrelevine: agree to go without the ROLE attribute for now? | 19:01 |
| pvaneck | yes | 19:01 |
| catherineD | I don't ... It just that each one of us are different and I respect everyone | 19:02 |
| sslypushenko | alexandrelevine: is right - RefStack is not widely used product, so we can extend it if it will be necessary | 19:02 |
| sslypushenko | so lets stick to alexandrelevine point and we will see how it will work for RefStack | 19:03 |
| sslypushenko | catherineD: so I agree to go without ROLE attribute for now | 19:04 |
| catherineD | so I take that the majority of us agree that no ROLE will be defined in the user-group column and thus no code to handle role | 19:04 |
| catherineD | good | 19:04 |
| catherineD | alexandrelevine: I guess we do not need to discuss point 2 -4 ? | 19:05 |
| alexandrelevine | let me check | 19:05 |
| alexandrelevine | catherineD: yes, no need | 19:06 |
| catherineD | I want to address point 5 ... | 19:06 |
| catherineD | I will mark done when I am done :-) | 19:06 |
| andrey-mp | my thoughts was: System stores openid everywhere and if we need to find groups we need two queries - firstly we should find id by openid and then find that we need | 19:08 |
| catherineD | for point 5 ... The spec just want to entertain the idea of built-in user-group ... I create the the spec for us to discuss .. I am not really a fan of it ... so going with group-user is fine with me .. done | 19:08 |
| catherineD | andrey-mp: I mean point 5 of alexandrelevine: 's statement above :-) | 19:08 |
| alexandrelevine | catherineD: I thought you were talking about the agenda items :) | 19:09 |
| andrey-mp | me too ) | 19:10 |
| catherineD | Nope but it is OK. On point 5 of your statement above. I guess this is an easy one to decide ... do everyone agree that we will create the user-group table and not the org-user table to store the user group relationshop? | 19:10 |
| sslypushenko | catherineD: agreed | 19:10 |
| alexandrelevine | catherineD: Can't we just name it Groups table? | 19:10 |
| alexandrelevine | catherineD: We'll have Organizations, Users, Groups. | 19:11 |
| catherineD | I am refering to the user-to-group table in https://review.openstack.org/#/c/268929/2/refstack/db/migrations/alembic/versions/319ee8fe47c7_create_group_table.py | 19:12 |
| alexandrelevine | catherineD: No, my bad. You're right. | 19:12 |
| catherineD | not the Group table itself | 19:12 |
| catherineD | pvaneck: ? | 19:12 |
| pvaneck | sure | 19:13 |
| catherineD | great ... now back to the agenda item 1.1.5 ... | 19:14 |
| catherineD | Using id which is an int and primary index vs openid which is using everywhere as andrey-mp: had pointed out | 19:15 |
| sslypushenko | the main issue here that user should be allowed to change openid | 19:16 |
| sslypushenko | if we allowed that we should keep things as is | 19:16 |
| alexandrelevine | sslypushenko: That sucks. | 19:17 |
| catherineD | sslypushenko: openid is not our control right? | 19:17 |
| andrey-mp | hm, user can't change openid - with new openid it will be a new user as I understand... | 19:17 |
| alexandrelevine | sslypushenko: How does it work at all? Is there no unique unchangeable ID for user? How is he traced to his previous openid in all of the object where it's stored? | 19:17 |
| sslypushenko | unfortunately we should work with openstackid implementation of openid | 19:18 |
| alexandrelevine | sslypushenko: Isn't andrey-mp: correct here? I also don't understand how it'd work | 19:18 |
| sslypushenko | and it might have some limitation | 19:18 |
| alexandrelevine | sslypushenko: But how does it work for openstackid? How everything traces the user afterwards? | 19:19 |
| sslypushenko | now it is does not work at all) | 19:19 |
| sslypushenko | user can not change openid | 19:20 |
| alexandrelevine | sounds funny :) | 19:20 |
| alexandrelevine | So why should we bother? | 19:20 |
| sslypushenko | actually we can do suggested change | 19:20 |
| sslypushenko | but firstly we need to check that openstackid will work with this solution | 19:21 |
| alexandrelevine | So we can rely on it to not be changed, right? Or we cannot? | 19:21 |
| sslypushenko | as far as I remember openstackid handles email change somewhat tricky... | 19:22 |
| catherineD | Just a time check ... I have a hard stop in 8 mins ... could you continue the discuss on the items in the agenda ... | 19:22 |
| andrey-mp | and also (right now), meta table contains openid as user identifier | 19:22 |
| catherineD | andrey-mp: you are right | 19:23 |
| sslypushenko | ok... let it be so | 19:23 |
| sslypushenko | but it needs to be rechecked | 19:23 |
| catherineD | I take that the agreement is to use openid ... | 19:23 |
| sslypushenko | yeap | 19:23 |
| catherineD | next ite, 1.2.1 on https://review.openstack.org/#/c/269066/ | 19:24 |
| catherineD | do we need approval? or type is good enought? sslypushenko: pvaneck: pls see inline comments .. | 19:24 |
| alexandrelevine | catherineD: This is a table for all Vendors, including hidden ones. We need to differentiate them. I suggest using the "type" instead of approved - more flexible for the future. | 19:25 |
| catherineD | alexandrelevine: I agree | 19:25 |
| sslypushenko | +1 | 19:25 |
| pvaneck | type is fine | 19:25 |
| catherineD | so we remove the approve column? | 19:25 |
| andrey-mp | which types will be defind in code right now? | 19:25 |
| andrey-mp | mmm, or we will change 'approved' to 'type' ? | 19:26 |
| catherineD | right now vendor, hidden_vendor, foundation | 19:26 |
| alexandrelevine | "Official", "Private"? | 19:26 |
| alexandrelevine | Yes, and "Foundation" | 19:26 |
| catherineD | andrey-mp: we should have type already .. | 19:26 |
| alexandrelevine | I don't like hidden_vendor | 19:27 |
| alexandrelevine | private is much better | 19:27 |
| catherineD | np on name the type colomn is int .. constant define by us | 19:27 |
| catherineD | next 1.2.2 product_id | 19:28 |
| catherineD | so for 1,2,1 we agree to remove 'approve' and use 'type' | 19:28 |
| alexandrelevine | We need unique_id for each of our entities. | 19:28 |
| catherineD | I think this is a longer discussion ... | 19:28 |
| catherineD | should we discuss this on Monday? | 19:28 |
| alexandrelevine | Too slow. | 19:29 |
| catherineD | meanwhile everyone please give your comments | 19:29 |
| alexandrelevine | We should start developing. In fact we started | 19:29 |
| catherineD | our you can discuss I will check the meeting log ... | 19:29 |
| catherineD | alexandrelevine:yay +++ | 19:29 |
| alexandrelevine | But what's the issue with the product_id? I don't see any | 19:29 |
| catherineD | please continue without me for now | 19:29 |
| sslypushenko | alexandrelevine: me too | 19:30 |
| sslypushenko | lets move to the last point | 19:30 |
| sslypushenko | I also prefer to have properties as meta_table | 19:31 |
| sslypushenko | instead of text blob | 19:31 |
| alexandrelevine | Last point: I don't personally care. I did it both ways. | 19:31 |
| alexandrelevine | Do we want to have meta_table for each of the other tables? It's sort of weird. | 19:32 |
| alexandrelevine | Maybe one for all then? | 19:32 |
| sslypushenko | So... we agreed to turn this field in to relation on product_meta table | 19:32 |
| sslypushenko | ? | 19:32 |
| alexandrelevine | andrey_mp: What do you think? | 19:32 |
| sslypushenko | if we need to store some attributes... I prefer to have metadata table | 19:33 |
| pvaneck | +1 on meta table for products | 19:33 |
| alexandrelevine | sslypushenko: I don't mind. I don't like multiplying meta tables | 19:33 |
| sslypushenko | alexandrelevine: me too but it is mysql( | 19:33 |
| andrey-mp | sslypushenko: so it will be second meta table? | 19:34 |
| sslypushenko | It will be much better to have DB in mongo... but it is as it is | 19:34 |
| alexandrelevine | sslypushenko: Then we'll need one for Organizations and one for Users. For sure. | 19:34 |
| andrey-mp | it is not so good ) | 19:34 |
| sslypushenko | why? | 19:35 |
| alexandrelevine | Because they'll require some extra properties eventually as well. They always do :) | 19:35 |
| sslypushenko | we already have enough code to operate meta data stored in key-value table | 19:35 |
| alexandrelevine | And we won't want to clutter DB columns with some extensive garbage which should not be indexed or searched for. | 19:35 |
| sslypushenko | hmm... so why we need it at all | 19:36 |
| alexandrelevine | But you're saying to create product_meta table. Meaning that it'll store extra properties for Products only. | 19:36 |
| sslypushenko | if we don't plan to search on it? | 19:36 |
| alexandrelevine | We need to store Tempest config for Clouds, for example. | 19:36 |
| alexandrelevine | We need it for various blobs or descriptive info | 19:36 |
| alexandrelevine | For Guidelines we'd want to store json and so on. | 19:37 |
| sslypushenko | so... I'm ok with having properties field for storing data which should be indexed | 19:38 |
| andrey-mp | and all these object will have 'one-to-many' links for object to meta | 19:38 |
| andrey-mp | but if we will use one meta table for all it will one huge table with hard indexies... | 19:38 |
| alexandrelevine | sslypushenko: Which "shouldn't" be indexed? | 19:38 |
| sslypushenko | if we don't have any other properties which requires to be indexed we can live without meta table for now | 19:39 |
| alexandrelevine | sslypushenko: Fine by me. Just an XML for any extra which is not searcheable | 19:39 |
| sslypushenko | json) | 19:39 |
| sslypushenko | NOT xml) please) | 19:39 |
| alexandrelevine | sslypushenko: Yes. Sorry :) | 19:39 |
| sslypushenko | good... so we come to common point on all questions, right? | 19:40 |
| pvaneck | yea, i can see why a properties field would be preferable now. let's stick with that then | 19:40 |
| alexandrelevine | I think so | 19:40 |
| andrey-mp | good! | 19:41 |
| sslypushenko | great! Anyone have something to add? | 19:41 |
| alexandrelevine | nope | 19:41 |
| andrey-mp | I'll rework reviews tomorrow and add some code to the second one | 19:41 |
| alexandrelevine | andrey-mp: perfect. Thahk you :) | 19:41 |
| sslypushenko | cool! | 19:41 |
| pvaneck | think we are all good. :) | 19:41 |
| andrey-mp | but i made one more review - https://review.openstack.org/#/c/268064/ | 19:42 |
| andrey-mp | it is not about surrent agenda | 19:42 |
| andrey-mp | it is about UI optimization ) | 19:42 |
| alexandrelevine | I think this one will be reviewed inside it, ok? | 19:42 |
| sslypushenko | ) pvaneck can you review it, please? | 19:42 |
| pvaneck | I'll merge that | 19:43 |
| sslypushenko | thx! | 19:43 |
| andrey-mp | thank you! | 19:43 |
| alexandrelevine | Ok. Then. Thank you and bye | 19:43 |
| sslypushenko | so... I think we do a great job today... thank you all) | 19:43 |
| sslypushenko | bye | 19:43 |
| *** alexandrelevine has quit IRC | 19:43 | |
| andrey-mp | bye | 19:44 |
| *** andrey-mp has quit IRC | 19:44 | |
| openstackgerrit | Merged openstack/refstack: Remove unused JS from UI https://review.openstack.org/268064 | 19:49 |
| *** dwalleck has joined #refstack | 20:43 | |
| openstackgerrit | Catherine Diep proposed openstack/refstack: Specification to add user/group support in RefStack https://review.openstack.org/269893 | 22:32 |
| openstackgerrit | Catherine Diep proposed openstack/refstack: Specification to add user/group support in RefStack https://review.openstack.org/269893 | 22:35 |
| *** davidlenwell has quit IRC | 22:37 | |
| *** davidlenwell has joined #refstack | 22:38 | |
| *** ChanServ sets mode: +o davidlenwell | 22:38 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!