19:03:27 #startmeeting refstack 19:03:28 Meeting started Mon Jan 11 19:03:27 2016 UTC and is due to finish in 60 minutes. The chair is catherineD. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:03:29 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:03:31 The meeting name has been set to 'refstack' 19:03:53 o/ 19:03:58 o/ 19:04:47 Happy New Year!!! 19:05:05 and in return! 19:05:06 Let wait for a few minutes 19:06:12 #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-01-11 19:07:27 We did not have a meeting last week because most of the team members were on vacation 19:07:37 o/ 19:08:09 alevine: welcome back ... Is today your first day back from holiday? 19:08:21 catherineD: Yes :) 19:08:35 o/ 19:08:58 #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-01-11 19:09:05 let's start 19:09:23 #topic Alex Levin's RefStack Requirements document 19:09:40 #link https://docs.google.com/document/d/1s_dAIuluztlCC6AZ-WO4_FR2CLje1QyS6kbMxlFHaMk/edit?usp=sharing 19:10:09 I know rockyg: and hogepodge: may not have a chance to review this doc ... 19:10:45 got that right, but skimming now... 19:10:56 alevine: seems like pvaneck: does not have the privilege to add comments ... 19:11:03 no i got that now 19:11:10 looks good 19:11:10 pvaneck: that is great .. 19:11:17 Seems to me the main remaining issue is in regards to to how regular users (user's not associated to a vendor) creating products should be handled? 19:11:25 catherineD: Have you had a chance to share it with Mark? Because I reviewed his spec and some of the explanations would've been given in the doc more clearly then in my comments to his spec. 19:12:19 alevine: I view your doc is the requirment and his spec is for implementation ... 19:12:53 catherineD: Nope 19:13:04 catherineD: His spec is mostly about requirement. 19:13:05 alevine: did you see my comments on Mark's spec? 19:13:16 catherineD: Yes. There were a couple. 19:14:24 alevine: I think the major disagreement is on how to handle group of users ... 19:15:04 In Mark's spec and my opinion, we manage this by creating a group entity 19:15:39 alevine: maybe you can explain your idea of build-in user group? 19:16:28 catherineD: I did in the doc. 19:16:37 catherineD: Let me copy-paste it here 19:17:20 By explicit Group I meant Group visible to the end-user. Internally a Group entity will exist and will be stored in the DB. Its ID will be an attribute of the corresponding Organization. It would be created along with Organization and destroyed along with it. It won't exist as a standalone thing. As I said - the built-in group. Same as a built-in groups, say, in Windows. 19:18:34 catherineD: I'm against having Group entity exposed to end user. I see it as an unnecessary complication for our implementation. Maybe it's not what's requested by Mark but it's how he wrote it. 19:18:46 I think maybe it's kinda the default group for an entity, maybe? 19:19:02 rockyg: Exactly 19:19:09 If group is not exposed to end users, how would this group be managed? 19:19:23 rockyg: The thing is, what I'm saying is that no other groups are needed besides those default ones. 19:19:36 group managed by entity owner 19:20:11 catherineD: Not as a group. User won't be able to create a new group or remove an existing one or list groups. He'll be able to manage user-admins for particular organization instead. Add them (Users), remove, list and so on. 19:20:12 rockyg: and entity owner is an end user , therefore group needed to be expose to end user 19:20:27 catherineD: Not the group. Its users. 19:20:58 catherineD: I'm saying there won't be means to list groups or manage them. But there will be means list and manage admins of particular organization. 19:21:54 I'm okay with this model 19:21:59 would the org-admin be able to list members of group? 19:22:37 rockyg: Of course. 19:23:06 I don't want us to implement "GROUP management". I want us to deal with "USER management" only. 19:23:15 pvaneck: perhaps you can describe the model per your understanding 19:23:41 so, all those functions are admin functions and end-user function is limited to listing name of the group and other properties, like maybe admin (need a contact in there;-) 19:23:43 just no explicit group creation/deletion that a user can initiate 19:23:53 group creations will be tied to the creation of orgs/products 19:24:09 pvaneck: Exactly 19:24:27 I think that is a reasonable way to go about it 19:25:18 alevine: from pvaneck: 's statement a group will also create when a product is created .. 19:25:49 catherineD: Could you rephrase? :) 19:26:08 My understanding of pvaneck: 's statement are: 19:26:37 1) when an organization is created ... a group will also be created 19:26:37 catherineD: Ah :) Yes a group will be created along with an organization (vendor). Not a product. 19:27:06 1) correct 19:27:06 2) when an product is created ... a group will also be created ... 19:27:48 2) Not initially. Only when we would introduce the per-product admins, which is not in the initial version. So, no. Initially it's not true. 19:28:17 who will manage the product ? 19:28:36 Admins of the Organization 19:28:42 The one which created the Product 19:29:18 so we need to have an Organization created before a product can be created ..? 19:29:33 sounds like. 19:29:50 Yes, that's why I wrote about hidden vendor for each User unless he's an admin of a registered vendor. 19:30:15 alevine: that is the point that I am not confortable with ... hidden vendor ... 19:30:38 how does RefStack differentiate hidden vs real vendors? 19:31:03 That's reasonable I guess. Product cannot be created out of thin air. So it's either Organization or User should create it. However I suggest simplifying the model by associating each User with his "self-employed" company, unless he works officially for a registered Vendor. 19:31:25 What do you mean by RefStack? 19:31:35 Describe the use-case. 19:31:36 In the RefStack code 19:32:30 A new user is registered. When he/she wants to create a product we create a Vendor for him/her, unless existed. Then the product is associated with that Vendor. That Vendor is not listed or anything. It's tightly associated with the User. 19:33:25 alevine: we agree with DefCore that vendor list will be provided by the Foundation ... 19:33:36 Redhat vs Rockys-redhat? What if a user submits multiple test results for multiple clouds? Let's call that user Monty ;-) 19:33:39 would having a product-group association eliminate the need for the hidden vendor creation. Just when a regular user creates a product, a group is created with the user as the admin? 19:33:46 catherineD: And? 19:34:17 rockyg: I tried to describe in the use-cases listed in the doc all the cases. I'll check this particular one. 19:34:19 RefStack will not provide vendor registration .... 19:34:38 pvaneck: No. It won't. 19:34:41 since vendor list will be imported from a list provided by foundation 19:35:28 pvaneck: It'll just drastically change the model and make it a little strange. Also, there is such a thing as Guidelines which also should be "owned" and they are not a Product. 19:35:30 alevine, I'm confused about #12 on pg 6. 19:36:15 catherineD: Ok. Let's say there is an "Organization" - some Organization, not requiring any registration. A private company. And there is Vendor which is registered by RefStack. Vendor will have official registration. 19:36:19 Yeah. Those guidelines are what are confusing me, as I am only aware of DefCore guidelines? 19:36:48 Or is this to allow things like EC2 guidelines added by a different group? 19:36:58 rockyg: that is the idea 19:37:30 rockyg: but we still want to take care of the DefCore cases first 19:37:32 catherineD: #12 is about user submitting new Guidelines for a someone else's Product. 19:37:53 rockyg: Yes, those are the external Products guidelines. 19:38:06 Why would a vendor need to approve the guidelines? They should be out there and if a vendor wants to run the tests, fine, they're official, but if others do, it's just a user's test set? 19:38:11 rockyg: You can see an example here: http://refstack.cloudscaling.com:8000/#/schemas 19:38:28 alevine: I don't think we want to have any one to create a Guideline 19:38:29 rockyg: They are called Schemas there at the moment. You can see AWS and PCF schemas. 19:38:47 Guideline should be created by a standard body like DefCore 19:39:15 rockyg: If I submit a new Guidelines for testing OpenStack definitely the Foundation would want to approve them before allowing anybody to test OpenStack with it, right? Same goes for any other Product. 19:39:50 alevine: we are really confused if we keep using the same term like "schema" for different things 19:39:51 catherineD: We already have. You won't be able to add external Products without new Guidelines. See the AWS. The won't be accepted by Foundation so we had to create and manage them. 19:40:36 for RefStack schema means what is stored in https://github.com/openstack/defcore/tree/master/doc/source/schema 19:40:38 catherineD: That's why I changed it in the doc to "Guidelines". It just stays named "schema" in the prototype for now. We'll change later of course. 19:40:54 catherineD: Of course I know. I mentioned it in the doc as well. 19:42:27 Suppose you created a new component for the OpenStack which is not yet accepted (or never be), say Manila (I don't remeber if it's accepted yet), and I want my users to start using Manila and validating clouds against my tests - I have to supply the tests and Guidelines for this, right? 19:45:58 Ah. So, doc needs more clarity on definitions. Guidelines are any test set specified by DefCore or approved for use on RefStack by Defcore. 19:46:16 alevine: I would say that scenareo will be managed by DefCore 19:46:52 and DefCore will put out a new Guideline as it did with 2016.01 (today) 19:46:58 Product includes non-openstack cloud apis and ecosystem products that are approved for testing against in Refstack 19:47:33 rockyg: Guideline is the like today's DefCore Guideline (2015.07, 2016.01 ..) 19:47:47 rockyg: No, not approved by DefCore. The won't manage external testing and external Products - that's what they said. And I agree. 19:47:56 rockyg: Guidelines - Output of the DefCore process detailing which sections and capabilities are required. Guidelines will be approved on a regular cadence and identified by the date of approval. Expressed by json. Guidelines must conform to one of the schema defined in https://github.com/openstack/defcore/tree/master/doc/source/schema 19:48:38 rockyg: That's the definition of DefCore. I didn't change it there. I can add that Guidelines can be created for External Products not managed and approved by DefCore. 19:49:45 OK. So, the EC2 list of tests aren't "guidelines", so "other compatability test sets"? Or some such? 19:49:52 rockyg: Product is refers to "software" or "cloud". Both are Products of some Vendor. Software is installed on Cloud and can be tested by some defined Guidelines. 19:50:18 And if DefCore isn't the body saying which test sets are ok to add to Refstack, who is? Foundation? TC? 19:50:37 rockyg: List of tests is not a Guidelines. But the json containing this list and names of tests and target programs is. 19:50:54 rockyg: Vendor. For its Products. 19:51:08 Because if it's a vendor, then Amazon would have to be the vendor to approve the EC2 tests, wouldn't it? 19:51:10 rockyg: Right now DefCore is such a Vendor for the Product OpenStack. 19:51:45 rockyg: That's correct. However Amazon doesn't care so we'll be representing it, since we created the EC2 API layer. 19:52:40 So i seem to see where you are going with the hidden vendor for each user creating a product or guideline. 19:52:44 Hmmm. So, again, who gives the go ahead to add to Refstack server since it's a foundation server? 19:52:59 alevine: If the same regular user creates multiple products, all these products would fall under the same hidden vendor for that user, right? 19:53:12 pvaneck: Great :) 19:53:47 alevine: pvaneck: I like that 19:53:49 In EC2 case, vendor would have to demonstrate right to use the trademarks and make the claims of compatibility? 19:54:11 hidden vendor is associated to a user not a product 19:54:15 Why can't refstack just take an external guideline as a parameter and evaluate a test result against it? 19:54:22 rockyg: According to the agreement with the DefCore guys the do not care if external tests get into their DB, so the Foundation (DefCore) manages and approves only the OpenStack related Products/Guidelines and each other Vendor works with his own stuff. 19:54:48 It's essentially what it does right now, just with the external uris hard coded to pull defcore because it is a special primary use case for refstack 19:54:52 pvaneck: Yes, exactly. 19:55:41 Then everyone can bring whatever guideline they want to the table, without a complex interface 19:55:52 ok we are discussing 2 topics at the same time now 19:55:57 OK. I suspect the Foundation would want to verify if any guideline claims compat to trademarked products, though. 19:56:17 rockyg: We're not doing nothing official for non-OpenStack Vendors. Those are just validations and the results. So no need to care about trademarks I guess. 19:56:43 hogepodge: Pretty much. 19:56:46 notes that 4 mins remaining ... 19:56:52 hogepoge: that is doable 19:57:15 I will need to end the meeting soon ... let's go to #refstack after this ... 19:57:52 rockyg: Well, I don't see why would they? There are no "claims" only results of tests and some "badges" (pictures) we show as a result of successful validation. 19:57:53 but I want to document our agreement regarding explicit/implicit user group creation 19:58:02 OK. Just the presence of the trademarked names, if there, might need to have some legalese or something...asterisk with the note at bottom of owner, etc. 19:58:19 catherineD: I'm sorry, can we continue tomorrow? 19:58:24 catherineD, ++ 19:58:27 sure ... 19:58:37 by one agreement we can log 19:58:41 And clarification in the doc, please? 19:59:05 rockyg: Probably you're right. We can take the trademarked names and base64-encode them to avoid problems :) (just a joke) 19:59:39 #agreed Group will be created implicitly. So, RefStack will provide user management and not group management. 19:59:42 rockyg: Clarification about the Guidelines which can be external? Could you please put your comments in the doc wherever you need any clarification? 19:59:48 I'll be more than happy to clarify 19:59:54 20:00:06 #endmeeting