19:03:27 <catherineD> #startmeeting refstack
19:03:28 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:03:31 <openstack> The meeting name has been set to 'refstack'
19:03:53 <rockyg> o/
19:03:58 <pvaneck> o/
19:04:47 <catherineD> Happy New Year!!!
19:05:05 <rockyg> and in return!
19:05:06 <catherineD> Let wait for a few minutes
19:06:12 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-01-11
19:07:27 <catherineD> We did not have a meeting last week because most of the team members were on vacation
19:07:37 <alevine> o/
19:08:09 <catherineD> alevine: welcome back ... Is today your first day back from holiday?
19:08:21 <alevine> catherineD: Yes :)
19:08:35 <hogepodge> o/
19:08:58 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-01-11
19:09:05 <catherineD> let's start
19:09:23 <catherineD> #topic Alex Levin's RefStack Requirements document
19:09:40 <catherineD> #link https://docs.google.com/document/d/1s_dAIuluztlCC6AZ-WO4_FR2CLje1QyS6kbMxlFHaMk/edit?usp=sharing
19:10:09 <catherineD> I know rockyg: and hogepodge: may not have a chance to review this doc ...
19:10:45 <rockyg> got that right, but skimming now...
19:10:56 <catherineD> alevine: seems like pvaneck: does not have the privilege to add comments ...
19:11:03 <pvaneck> no i got that now
19:11:10 <pvaneck> looks good
19:11:10 <catherineD> pvaneck: that is great ..
19:11:17 <pvaneck> 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 <alevine> 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 <catherineD> alevine: I view your doc is the requirment and his spec is for implementation ...
19:12:53 <alevine> catherineD: Nope
19:13:04 <alevine> catherineD: His spec is mostly about requirement.
19:13:05 <catherineD> alevine: did you see  my comments on Mark's spec?
19:13:16 <alevine> catherineD: Yes. There were a couple.
19:14:24 <catherineD> alevine: I think the major disagreement is on how to handle group of users ...
19:15:04 <catherineD> In Mark's spec and my opinion, we manage this by creating a group entity
19:15:39 <catherineD> alevine: maybe you can explain your idea of build-in user group?
19:16:28 <alevine> catherineD: I did in the doc.
19:16:37 <alevine> catherineD: Let me copy-paste it here
19:17:20 <alevine> 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 <alevine> 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 <rockyg> I think maybe it's kinda the default group for an entity, maybe?
19:19:02 <alevine> rockyg: Exactly
19:19:09 <catherineD> If group is not exposed to end users, how would this group be managed?
19:19:23 <alevine> rockyg: The thing is, what I'm saying is that no other groups are needed besides those default ones.
19:19:36 <rockyg> group managed by entity owner
19:20:11 <alevine> 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 <catherineD> rockyg: and entity owner is an end user , therefore group needed to be expose to end user
19:20:27 <alevine> catherineD: Not the group. Its users.
19:20:58 <alevine> 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 <pvaneck> I'm okay with this model
19:21:59 <rockyg> would the org-admin be able to list members of group?
19:22:37 <alevine> rockyg: Of course.
19:23:06 <alevine> I don't want us to implement "GROUP management". I want us to deal with "USER management" only.
19:23:15 <catherineD> pvaneck: perhaps you can describe the model per your understanding
19:23:41 <rockyg> 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 <pvaneck> just no explicit group creation/deletion that a user can initiate
19:23:53 <pvaneck> group creations will be tied to the creation of orgs/products
19:24:09 <alevine> pvaneck: Exactly
19:24:27 <pvaneck> I think that is a reasonable way to go about it
19:25:18 <catherineD> alevine: from pvaneck: 's statement a group will also create when a product is created ..
19:25:49 <alevine> catherineD: Could you rephrase? :)
19:26:08 <catherineD> My understanding of pvaneck: 's statement are:
19:26:37 <catherineD> 1) when an organization is created ... a group will also be created
19:26:37 <alevine> catherineD: Ah :) Yes a group will be created along with an organization (vendor). Not a product.
19:27:06 <alevine> 1) correct
19:27:06 <catherineD> 2) when an product is created ... a group will also be created ...
19:27:48 <alevine> 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 <catherineD> who will manage the product ?
19:28:36 <alevine> Admins of the Organization
19:28:42 <alevine> The one which created the Product
19:29:18 <catherineD> so we need to have an Organization created before a product can be created ..?
19:29:33 <rockyg> sounds like.
19:29:50 <alevine> Yes, that's why I wrote about hidden vendor for each User unless he's an admin of a registered vendor.
19:30:15 <catherineD> alevine: that is the point that I am not confortable with ... hidden vendor ...
19:30:38 <catherineD> how does RefStack differentiate hidden vs real vendors?
19:31:03 <alevine> 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 <alevine> What do you mean by RefStack?
19:31:35 <alevine> Describe the use-case.
19:31:36 <catherineD> In the RefStack code
19:32:30 <alevine> 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 <catherineD> alevine: we agree with DefCore that vendor  list will be provided by the Foundation ...
19:33:36 <rockyg> Redhat vs Rockys-redhat?  What if a user submits multiple test results for multiple clouds?  Let's call that user Monty ;-)
19:33:39 <pvaneck> 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 <alevine> catherineD: And?
19:34:17 <alevine> 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 <catherineD> RefStack will not provide  vendor registration ....
19:34:38 <alevine> pvaneck: No. It won't.
19:34:41 <catherineD> since vendor list will be imported from a list provided by foundation
19:35:28 <alevine> 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 <rockyg> alevine, I'm confused about #12 on pg 6.
19:36:15 <alevine> 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 <rockyg> Yeah.  Those guidelines are what are confusing me, as I am only aware of DefCore guidelines?
19:36:48 <rockyg> Or is this to allow things like EC2 guidelines added by a different group?
19:36:58 <catherineD> rockyg: that is the idea
19:37:30 <catherineD> rockyg: but we still want to take care of the DefCore cases first
19:37:32 <alevine> catherineD: #12 is about user submitting new Guidelines for a someone else's Product.
19:37:53 <alevine> rockyg: Yes, those are the external Products guidelines.
19:38:06 <rockyg> 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 <alevine> rockyg: You can see an example here: http://refstack.cloudscaling.com:8000/#/schemas
19:38:28 <catherineD> alevine: I don't think we want to have any one to create a Guideline
19:38:29 <alevine> rockyg: They are called Schemas there at the moment. You can see AWS and PCF schemas.
19:38:47 <catherineD> Guideline should be created by a standard body like DefCore
19:39:15 <alevine> 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 <catherineD> alevine: we are really confused if we keep using the same term like "schema" for different things
19:39:51 <alevine> 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 <catherineD> for RefStack schema means what is stored in https://github.com/openstack/defcore/tree/master/doc/source/schema
19:40:38 <alevine> 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 <alevine> catherineD: Of course I know. I mentioned it in the doc as well.
19:42:27 <alevine> 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 <rockyg> 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 <catherineD> alevine: I would say that scenareo will be managed by DefCore
19:46:52 <catherineD> and DefCore will put out a new Guideline as it did with 2016.01 (today)
19:46:58 <rockyg> Product includes non-openstack cloud apis and ecosystem products that are approved for testing against in Refstack
19:47:33 <catherineD> rockyg: Guideline is the like today's DefCore Guideline (2015.07, 2016.01 ..)
19:47:47 <alevine> 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 <alevine> 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 <alevine> 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 <rockyg> OK.  So, the EC2 list of tests aren't "guidelines", so "other compatability test sets"? Or some such?
19:49:52 <alevine> 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 <rockyg> And if DefCore isn't the body saying which test sets are ok to add to Refstack, who is?  Foundation?  TC?
19:50:37 <alevine> 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 <alevine> rockyg: Vendor. For its Products.
19:51:08 <rockyg> 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 <alevine> rockyg: Right now DefCore is such a Vendor for the Product OpenStack.
19:51:45 <alevine> 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 <pvaneck> So i seem to see where you are going with the hidden vendor for each user creating a product or guideline.
19:52:44 <rockyg> Hmmm.  So, again, who gives the go ahead to add to Refstack server since it's a foundation server?
19:52:59 <pvaneck> 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 <alevine> pvaneck: Great :)
19:53:47 <catherineD> alevine: pvaneck: I like that
19:53:49 <rockyg> In EC2 case, vendor would have to demonstrate right to use the trademarks and make the claims of compatibility?
19:54:11 <catherineD> hidden vendor is associated to a user not a product
19:54:15 <hogepodge> Why can't refstack just take an external guideline as a parameter and evaluate a test result against it?
19:54:22 <alevine> 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 <hogepodge> 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 <alevine> pvaneck: Yes, exactly.
19:55:41 <hogepodge> Then everyone can bring whatever guideline they want to the table, without a complex interface
19:55:52 <catherineD> ok we are discussing 2 topics at the same time now
19:55:57 <rockyg> OK.  I suspect the Foundation would want to verify if any guideline claims compat to trademarked products, though.
19:56:17 <alevine> 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 <alevine> hogepodge: Pretty much.
19:56:46 <catherineD> notes that 4 mins remaining ...
19:56:52 <pvaneck> hogepoge: that is doable
19:57:15 <catherineD> I will need to end the meeting soon ... let's go to #refstack after this ...
19:57:52 <alevine> 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 <catherineD> but I want to document our agreement regarding explicit/implicit user group creation
19:58:02 <rockyg> 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 <alevine> catherineD: I'm sorry, can we continue tomorrow?
19:58:24 <rockyg> catherineD, ++
19:58:27 <catherineD> sure ...
19:58:37 <catherineD> by one agreement we can log
19:58:41 <rockyg> And clarification in the doc, please?
19:59:05 <alevine> rockyg: Probably you're right. We can take the trademarked names and base64-encode them to avoid problems :) (just a joke)
19:59:39 <catherineD> #agreed Group will be created implicitly.  So, RefStack will provide user management and not group management.
19:59:42 <alevine> 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 <alevine> I'll be more than happy to clarify
19:59:54 <rockyg> <snicker>
20:00:06 <catherineD> #endmeeting