19:00:21 <catherineD> #startmeeting refstack
19:00:22 <openstack> Meeting started Tue May 24 19:00:21 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:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:26 <openstack> The meeting name has been set to 'refstack'
19:00:45 <andrey-mp> hi
19:00:46 <catherineD> Roll call
19:01:00 <catherineD> andrey-mp: hi
19:01:25 <pvaneck> o/
19:01:33 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-05-24
19:01:57 <rockyg> o/
19:02:18 <catherineD> Agenda https://etherpad.openstack.org/p/refstack-meeting-16-05-24
19:02:30 <catherineD> pvaneck: rockyg: hi
19:02:42 <catherineD> #topic Pending reviews
19:03:06 <catherineD> #link Add products REST API  (  https://review.openstack.org/#/c/315743/ )
19:03:15 <hogepodge> o/
19:03:40 <catherineD> agenda https://etherpad.openstack.org/p/refstack-meeting-16-05-24
19:04:10 <catherineD> Item 1.1.1 Do we allow Foundation organization to create product?
19:04:34 <andrey-mp> foundation users are admins - they can all )
19:04:54 <catherineD> For RefStack , ther will be one organization named "Foundation" ...
19:05:42 <catherineD> the users on this organization are essentially supper users ...
19:06:06 <catherineD> the question is as a Foundation organization ... will Foundation ever own products?
19:06:42 <rockyg> Well, they certainly could /do own training products
19:07:08 <pvaneck> i dont see why we should limit them
19:07:36 <catherineD> hogepodge: your thought?
19:08:22 <hogepodge> I wouldn't be creating any products, but if there's effort involved in restrictions then why bother?
19:08:41 <hogepodge> Focus on core functionality
19:09:16 <catherineD> hogepodge: we could check if the organization type is foudation then we do not allow it to create product
19:09:53 <catherineD> https://review.openstack.org/#/c/315743/3/refstack/api/controllers/products.py line 119
19:11:09 <catherineD> Seems like majority of us do not think that we need that check?
19:11:29 <pvaneck> catherineD: just allow them to do everything. I dont think we should be putting restrictions on them. There may be a case where they need that ability sometime
19:11:31 <hogepodge> I really don't have strong feelings wither way
19:11:40 <catherineD> ok
19:11:55 <rockyg> nah.  can be added if we have an issue.  Trust the Foundation
19:12:22 <catherineD> #agreed Allow Foundation organization to create products
19:12:25 <catherineD> moving on
19:13:17 <catherineD> item 1.1.2 has resovled ... there will be only one default vendor per user
19:13:30 <andrey-mp> agreed
19:13:59 <catherineD> item 1.1.3 Do we allow product to  be viewable by the public when its vendor is not ?
19:14:17 <catherineD> the use case is the default vendor will never be a public vendor
19:14:53 <catherineD> rockyg: hogepodge: FYI, per RefStack design all products must owned byt a vendor
19:15:16 <hogepodge> I can create devstack product now. :-D
19:15:17 <andrey-mp> catherineD: I think that this is two different use cases
19:15:20 <catherineD> for individual person, we allow he/she to be his/her own vendor
19:15:33 <rockyg> Gee, owned by the foundation, even!
19:15:41 <catherineD> andrey-mp: how so?
19:16:08 <catherineD> rockyg: yes
19:17:03 <andrey-mp> 1. default vendor is just a vendor. only Foundation can tell - can it be public or not
19:17:16 <catherineD> rockyg: so if you log in and create a product unless you sepecify that the product you  create belong to vendor Huawei,,, by default that product belong to you as an individual ..
19:17:46 <andrey-mp> 2. original question - Do we allow product to  be viewable by the public when its vendor is not ?
19:17:58 <catherineD> andrey-mp: in my mind, default vendor should not be public
19:18:14 <andrey-mp> catherineD: I agree with this )
19:19:05 <andrey-mp> but second case is not followed from first
19:19:09 <rockyg> Also, how will people  see an individual's result against a vendor's product if the individual has to be public for their results to show?
19:19:48 <rockyg> The individual  wants to be "anonymous"  to everyone but the foundation
19:20:02 <catherineD> rockyg: that is andrey-mp:'s question #2
19:21:15 <catherineD> Therefore I would think that for question #2 we should allow product to be viewable by the public when its vendor is not ... in that case the product is just an anonymous product
19:21:23 <rockyg> We could have default vendor be "anonymous" and anyone who doesn't put in a vendor gets put into "anonymous"
19:21:38 <rockyg> Then Anonymous is public and results can be seen
19:22:20 <andrey-mp> rockyg: it's simplier to allow make products public even if vendor is not
19:22:36 <catherineD> andrey-mp: +1
19:22:43 <rockyg> andrey-mp, ok
19:23:39 <andrey-mp> hogepodge: what is your thoughts?
19:24:04 <hogepodge> I get lots of anonymous refstack results
19:24:36 <catherineD> so the creator can  decide whether  data is public or not (today's implementation).  He/she can also decide whether the product is public or not .... the product may/or may not have test results associated to it
19:24:39 <hogepodge> so I will need time to a) capture them permanently, and b) encourage vendors to use new features that link products
19:25:21 <hogepodge> but if they submit results, then those results need to be public to satisfy public reporting requirement for defcore
19:25:21 <catherineD> hogepodge: and the product need to link to a vendor (other then default vendor)
19:26:12 <hogepodge> Two use cases
19:26:22 <catherineD> hogepodge: absolutely  .. the results will behave as it is today ... if upload anonymously will be public ... if upload with signature then the user can decide on share or not share
19:26:28 <hogepodge> 1) vendor wants to publicly report results. Must be public
19:26:43 <hogepodge> 2) end user wants to report on cloud they use. IMO, must also be public
19:27:20 <hogepodge> question: allow reporting of results against product? Feels like something we want to do for accountability, but, is easily abused
19:27:34 <catherineD> hogepodge: case 1) vendor must be public., product must be public and the result mist be public
19:27:35 <andrey-mp> hogepodge: catherineD: we agreed on summit that user can upload results specifying product_id. and these results will be linked to specific product
19:28:05 <hogepodge> andrey-mp: how do we handle objections? i.e. vendor objecting to misconfigured testing
19:28:15 <catherineD> andrey-mp: correct ... that is why we should allow the product to be public even if the vendor is not
19:28:54 <andrey-mp> hogepodge: i'm sorry - what objection is?
19:29:41 <catherineD> hogepodge: in that case the data only associate to  the product no vendor (since it is an individual vendor)  ..
19:30:37 <catherineD> so the data is regarded as individual opinion ..
19:31:06 <hogepodge> catherineD: how do we reduce confusion between individual results and vendor results?
19:31:36 <rockyg> hogepodge, and if it's malicious, the vendor can appeal to defcore to remove  the data/ban user/whatever
19:31:52 <hogepodge> not even malicious, just incorrect
19:32:03 <catherineD> hogepodge: vendor results will have vendor name displayed .. only official vendor (approved by foundation) can have vendor name displayed
19:33:02 <catherineD> this is why the default_vendor (individual vendor) can never be public
19:34:19 <catherineD> so the dangerous thing is the individual can name the product name that can point to a vendor product ...
19:35:18 <catherineD> the other way is to not allow viewable of products that vendor is not public
19:37:27 <andrey-mp> catherineD: in this case it is hard to make results viewable... either all can't see results of private vendor or user should share individual results (like now)
19:38:27 <catherineD> andrey-mp: in that case results will be viewable as it is today without product or vendor association ..
19:38:42 <andrey-mp> yeah
19:39:00 <andrey-mp> just 'this results from user A'
19:40:12 <catherineD> hogepodge: rockyg: the key point here is ... do we want to make individual (not vendor)  result easily regonizable ... or we can keep it the way it is today ...
19:40:33 <catherineD> only associate data to product of official vendor
19:41:08 <andrey-mp> catherineD: is it right - individual results are a not linked to product ?
19:41:41 <andrey-mp> or individual results are results of private vendor ?
19:41:44 <rockyg> good question.  Don't have an answer yet.  that's what happens when you spring something on me from left field!
19:42:10 <catherineD> individual results can link or not link to a product
19:42:32 <andrey-mp> official vendor can have private products as I understand...
19:42:41 <catherineD> andrey-mp: correct
19:43:08 <andrey-mp> catherineD: so what do you mean when name results as 'individual'? )
19:43:38 <catherineD> rockyg: sorry no need for answer today ... just think about it ... we can revisit next week
19:44:32 <rockyg> Thanks!
19:44:54 <catherineD> andrey-mp: so data can be uploaded with or without product_id associated to it .... and the user can decide whether the data is share or not share
19:46:09 <catherineD> individual means any one can upload data wiht or without product associated to it
19:46:48 <andrey-mp> so it just a test results...
19:47:15 <catherineD> andrey-mp: yes
19:47:21 <andrey-mp> ok )
19:48:00 <catherineD> now sharing of results without product associated with it is the case we have today
19:48:36 <catherineD> there is not way the anyone other than the individual know the origin of the data ...
19:48:43 <andrey-mp> catherineD: and what means your phrase - "do we want to make individual (not vendor)  result easily regonizable" ?
19:49:56 <catherineD> when we associated the data to a product that own by non official vendor (default vendor) ...since the product is created by an individual of non official vendor
19:50:42 <catherineD> there is no way for us to stop the individual to name the product as "IBM cloud" for example
19:51:30 <andrey-mp> so 'individual results' means that these result either not linked to any product or linked to product that linked to non-Official vendor. right?
19:51:31 <catherineD> since we allow viewing of non-official product ... people can be confused that this is official product
19:51:59 <catherineD> andrey-mp: yes
19:52:29 <andrey-mp> and these results can change status if vendor becomes Official. right?
19:52:52 <catherineD> I believe that is the confusion that hogepodge: warns us
19:53:26 <rockyg> Well, it's confusing to me.  I need to see a flowchart.
19:54:23 <andrey-mp> ok. So why we need this name for results - 'individual'? let's treat results public or private. it will be simplier for understanding
19:55:03 <catherineD> andrey-mp: ok
19:55:33 <catherineD> rockyg: we will see what we can do ... I believe we have description on the requirement doc
19:55:54 <catherineD> let's revisit this topic next week
19:56:17 <catherineD> very quickly
19:56:30 <andrey-mp> then we have a question - should we make all results public if product becomes public
19:56:32 <catherineD> andrey-mp: item 1.3  ... I think we can merge this one
19:56:44 <rockyg> Cool.  Would be good for the site docs.
19:57:04 <catherineD> and also item 1.2     Add preliminary support for schema version 1.5  (  https://review.openstack.org/#/c/319057/  )
19:57:12 <andrey-mp> catherineD: ok
19:57:28 <catherineD> hogepodge: please review https://review.openstack.org/#/c/319057/
19:57:35 <hogepodge> k
19:57:58 <catherineD> ok let's review the product topic next week ...
19:59:35 <catherineD> I guess for the rest of the topic we can discuss on #refstack if needed or revisit next week
19:59:44 <catherineD> need to end the meeting now
19:59:51 <catherineD> thank you all!
20:00:04 <catherineD> #endmeeting