19:10:56 <catherineD> #startmeeting refstack
19:10:57 <openstack> Meeting started Mon Jan 25 19:10:56 2016 UTC and is due to finish in 60 minutes.  The chair is catherineD. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:10:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:11:01 <openstack> The meeting name has been set to 'refstack'
19:11:29 <rockyg> o/
19:11:31 <pvaneck_> o/
19:12:08 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-01-25
19:12:20 <catherineD> I need to wake up :-)
19:12:39 <catherineD> #topic User/group spec and implementation merged !!!!
19:13:31 <catherineD> #topic Organization and product entities
19:13:55 <catherineD> #link     Database tables spec :  https://review.openstack.org/#/c/268922/
19:14:05 <catherineD> #link     Implementation :  https://review.openstack.org/#/c/269066/
19:14:23 <catherineD> #link do we need the 'public' field ? line 35  https://review.openstack.org/#/c/269066/10/refstack/db/migrations/alembic/versions/7092392cbb8e_create_product_table.py
19:14:52 <catherineD> what is this field for?
19:15:43 <alexandrelevine> catherineD: Well, I thought Andrey answered the question in the review. Several use-cases require it
19:15:59 <andrey-mp> I've tried to describe it in your review - https://review.openstack.org/#/c/268922/2/specs/mitaka/approved/vendor-registration-data-model.rst line 99
19:16:45 <catherineD> do we allow community to list a product?  what would that be that usecase?
19:17:04 <alexandrelevine> catherineD: What do you mean "to list a product"?
19:17:07 <catherineD> in my mind what we are sharing is a test result..
19:17:34 <rockyg> that's the "anyone can upload test results against a cloud" req.
19:17:48 <alexandrelevine> catherineD: All of our entities can be private or public, including Products, Vendors, test results, Guidelines, etc.
19:18:12 <catherineD> when we share a test result, if the test result is link to a product ... then product name would be shown ... so to me the share flag should be at the test record level ...
19:18:59 <alexandrelevine> catherineD: You can share test result now and the product is not there at all. It can stay exactly this way. Until the product is officially published, test result is anonymous.
19:19:48 <catherineD> alexandrelevine: would that be confusing with 2 share flag one at test results and one at the product level?
19:20:50 <alexandrelevine> catherineD: I don't see why. Those are rather independent entities.
19:20:52 <catherineD> alexandrelevine: this is for the case when the product is link to the test results ... and the user should have the choice to not share the result of a product
19:21:42 <sslypushenko> alexandrelevine: Should we drop public flag for test result in this case?
19:21:43 <catherineD> can we share the product and not share the test result associate to it?
19:21:53 <sslypushenko> catherineD: +1
19:22:15 <catherineD> sslypushenko: a product may have many test runs and not all of then are shared ..
19:22:38 <catherineD> so IMO we need the flag at the test level ..
19:22:44 <rockyg> So, I think what is confusing is that with user, share==public, but with product, share==public or published.  So, words in docs use shar, public, etc, but the field in all the tables should be named the same.
19:23:06 <alexandrelevine> You can see in the Domain model, that Test Run is associated with the Cloud only. And Cloud is a Product, but it also is associated with Software which is also Products.
19:23:58 <sslypushenko> alexandrelevine: All test results  will be associated with Clouds?
19:24:02 <alexandrelevine> catherineD: Yes we can share a Product and not share a test result associated to it.
19:24:21 <rockyg> sslypushenko, don't they have to?
19:24:23 <catherineD> alexandrelevine: I understand the model ... I am questioning what is the function of sharing a product in the reality ... it just allow listing of the prodcuts?
19:24:34 <alexandrelevine> sslypushenko: Well, one definitely runs tests in against a Cloud, right? There is no way around it in our world :)
19:24:43 <sslypushenko> rockyg: Trying to get the point
19:25:34 <sslypushenko> alexandrelevine: In this case 'public' field for Product is working for me
19:25:37 <alexandrelevine> catherineD: Yes, it allows publishing of Clouds and Software, which can subsequently be viewed, associated with more tests, etc.
19:25:45 <catherineD> alexandrelevine: yes but test run can only be initiated by a validated user regardless of whether the product is shared or not
19:26:10 <alexandrelevine> catherineD: Correct. And?
19:26:42 <alexandrelevine> catherineD: By the way, not exactly correct. You told me that there are cases when anonymous use runs tests in a cloud
19:26:47 <catherineD> alexandrelevine: we do not need to check the public attribute for running test
19:27:21 <rockyg> catherineD, a user can publish test results against a product, but until the product itself is public, all the user is sharing is cloud test results, not product (officially, at least)
19:27:32 <catherineD> alexandrelevine: anonymous user can run tests on its own cloud not any cloud ...
19:27:48 <alexandrelevine> catherineD: I'm a user. I have my cloud. I run my tests. Everything is private. I do not want to show it to anybody else. It stays private. Afterwards I decided to provide my tests for analysis or browsing. I publish them. My cloud still stays private.
19:28:29 <catherineD> alexandrelevine: yes you publish your test results not your cloud ...
19:28:45 <alexandrelevine> catherineD: There is no such thing as "a cloud of anonymous user". From our point of view at least. We just get results with cloudID and no User ID. We have no idea who hacked what and run where.
19:28:57 <catherineD> the results will have cloud name (product name/ organization name )assiciated to it
19:29:04 <alexandrelevine> catherineD: I still don't understand the question and the problem.
19:29:32 <alexandrelevine> catherineD: There is no such thing as a cloud name at the moment. And if nobody registered such a cloud it still doesn't exist. But test results do.
19:29:55 <sslypushenko> alexandrelevine: +1... It looks like 'public' should be helpful
19:30:19 <alexandrelevine> catherineD: Moreover. If I registered a cloud and I'm an approved vendor I still can leave it private and you'll see my results if I share them but not the name of my cloud.
19:30:20 <catherineD> sslypushenko: alexandrelevine: please explain the usecase again?
19:30:36 <alexandrelevine> catheriheD: Which one?
19:31:54 <alexandrelevine> catherineD: We have use-cases 17, 23 and 30.
19:31:59 <catherineD> I am not convince that we need the public attribute in the product .... l
19:32:15 <alexandrelevine> catherineD: Basically, they require the "public" to be for those entities.
19:32:52 <catherineD> ok let me review the usecases ... let's revisit later ...
19:33:02 <alexandrelevine> catherineD: I'm sorry, we should go back to the requirements doc then, not the implementation if we disagree about such things.
19:33:03 <catherineD> let's move to the next item ...
19:33:36 <catherineD> alexandrelevine:that is why I want to move to next item so I can review the doc ...
19:34:32 <catherineD> I do not want read offline so we can discuss the next item ...
19:34:52 <catherineD> are we ok with?  or do we want to stay on this topic?
19:35:04 <rockyg> +1 next topic
19:35:07 <sslypushenko> +1
19:35:09 <alexandrelevine> you decide :) I still don't understand the problem
19:35:54 <catherineD> alexandrelevine:  we will revist ... we will come to agreement just like what we have done ...
19:36:01 <alexandrelevine> sure
19:36:42 <catherineD> #topic How do we want to save the URL in the product table?
19:37:42 <catherineD> is that the product_id field in andrey-mp: 's patch https://review.openstack.org/#/c/269066/13/refstack/db/migrations/alembic/versions/7092392cbb8e_create_product_table.py
19:38:13 <catherineD> catherineD: this is only needed for future "Centralized testing"
19:39:13 <alexandrelevine> catherineD: What do you mean "future"? :) We plan to implement it very soon. Guidelines are already there.
19:40:19 <alexandrelevine> catherineD: And by the way, since Cloud is a Product - the Product ID will store cpid and other Cloud IDs. So it's not future at all.
19:40:41 <catherineD> alexandrelevine: that would be great ... Let me re-phrase ... that field is only needed for Centralized testing
19:40:52 <alexandrelevine> catherineD: Not correct.
19:41:57 <catherineD> we have an ID field (UUID) to identify this product record ...
19:43:13 <alexandrelevine> That's the previously named "_id" internal id isn't it?
19:43:21 <catherineD> Many clouds can be represent a  software product ... only cloud should be certified for a software product ...
19:43:47 <alexandrelevine> catherineD: I didn't quite understand this
19:43:56 <catherineD> it is now ID and is public
19:45:17 <rockyg> I'm with alexandrelevine.  I'm confused by your many clouds statement
19:45:25 <catherineD> since test can be initiated on-premise by vendor, they can build clouds for the product ... we can not enforce that they use the same URL all the time ..
19:46:10 <catherineD> rockyg: Huawei testing one of your product ... do you enforced that the cloud has to be built with the same URL all the time?
19:46:25 <alexandrelevine> catherineD: id is a GUID, created by DB during object creation. Product_ID is a place to store cpid and such.
19:47:15 <andrey-mp> cpid or cloud URL
19:47:18 <catherineD> alexandrelevine:  should we use CPID instead of Product_ID?
19:47:24 <catherineD> andrey-mp: +1
19:47:35 <catherineD> that would be clearer ...
19:48:12 <catherineD> and this field is very important for centralized testing but not for on-premise testing
19:48:17 <andrey-mp> catherineD: but this table for clouds and products and it is better to store these ids in one field
19:48:20 <alexandrelevine> catherineD: Now we shouldn't.
19:48:36 <alexandrelevine> catherineD: Because cpid is just one of the cases of various Product IDs.
19:48:49 <sslypushenko> alexandrelevine: +1
19:48:57 <catherineD> alexandrelevine: for software product it is one of the cases
19:49:03 <alexandrelevine> catherineD: For which we have now external Cloud URL and will have Software Product ID whatever it is.
19:49:15 <catherineD> for centralized testing it should be unique?
19:49:32 <alexandrelevine> catherineD: There is no difference between centralized or any other kind of testing.
19:49:39 <catherineD> thers is ...
19:49:42 <alexandrelevine> catherineD: It's just the way you invoke tests.
19:49:59 <catherineD> if I go to Amazone there should be one URL right?
19:50:23 <alexandrelevine> catherineD: Uniqueness of the Cloud being tests doesn't suffer because of the way we invoke our tests.
19:50:29 <catherineD> if I install a cloud on-premise to test my product then there can be manyu clouds
19:50:50 <alexandrelevine> catherineD: If we don't separate Amazon regions, yes, there will be one URL, correct.
19:51:28 <alexandrelevine> catherineD: Those will be different clouds, yes. Many but different. (if you installed many)
19:51:58 <catherineD> alexandrelevine: if you sepatate Amazon regions ... are they belong to one product?
19:52:48 <catherineD> and if you have many URLs how do you differentiate them?
19:52:56 <alexandrelevine> catherineD: By Product you mean Cloud now, correct? If so, the answer is no - if we separated Amazon regions, we'll do this to consider them different Clouds, i.e. different Products. If we don't separate them - it'll be one Cloud, i.e. one Product
19:53:53 <alexandrelevine> catherineD: How do you differentiate different URLs? I don't know :) I don't. They are just different. And if a Cloud is represented by a different cpid or URL, it's a different Cloud. I still don't understand the question, I'm affraid.
19:53:58 <catherineD> A product is a record that save in the product table ... a product can be software product (representing by a private cloud) or a public cloud
19:54:27 <alexandrelevine> catherineD: This is an incorrect statement.
19:54:42 <catherineD> alexandrelevine: please explain
19:55:18 <alexandrelevine> catherineD: Software Product and Cloud are different Products. So "a product can be software product (representing by a private cloud)" is not correct to say.
19:55:48 <catherineD> how do we test a software product?
19:56:00 <alexandrelevine> catherineD: You talked me into combining both Software and Clouds into one entity - Product, remember? :)
19:56:08 <catherineD> yes ...
19:56:48 <alexandrelevine> catherineD: You test a Cloud which has some Software Products installed. Each Software Product is associated with Guidelines which defines which tests test this Software Product.
19:57:05 <catherineD> so a software product is actually a cloud with undetermine cloud implementation
19:57:13 <alexandrelevine> catherineD: So when the tests are run we can deduce which correspond to which Software Product in this particular Cloud.
19:57:32 <alexandrelevine> catherineD: Software Product is NOT a Cloud.
19:57:47 <catherineD> alexandrelevine: correct ..
19:57:55 <alexandrelevine> catherineD: Software Product is a software associated with the Cloud.
19:57:58 <catherineD> ok let me ask in a different way
19:58:34 <catherineD> how do we associate a software product to a cloud?
19:59:03 <catherineD> we only have 2 mins left ...
19:59:33 <catherineD> let's move to #refstack ... is it OK for everyone?
19:59:46 <alexandrelevine> catherineD: We don't have to now. We can if we want, but we don't have to. Let's move to refstack and I explain.
20:00:19 * redrobot clears throat
20:00:19 <andrey-mp> ok
20:00:30 <catherineD> sslypushenko: BTW, thanks for letting me know that I had started the meeting in the wrong place :-)
20:00:36 <catherineD> #endmeeting