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