19:00:07 <catherineD> #startmeeting refstack 19:00:08 <openstack> Meeting started Tue Aug 16 19:00:07 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:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:12 <openstack> The meeting name has been set to 'refstack' 19:01:07 <andrey-mp> o/ 19:01:52 <pvaneck> o/ 19:01:59 <catherineD> #link meeting agenda and notes, https://etherpad.openstack.org/p/refstack-meeting-16-08-16 19:03:07 <sslypushenko> o/ 19:03:42 <catherineD> hello everyone ... let's start 19:03:48 <catherineD> #topic Restrict test result metadata keys 19:04:31 <catherineD> #link Restrict test result metadata keys https://review.openstack.org/#/c/348581/ 19:04:38 <sslypushenko> merged) 19:05:10 <catherineD> sslypushenko: thank yo uso much!!! I don't feel very comfortable that we expose user OpenID 19:05:38 <catherineD> andrey-mp: I think you caught that right? Thanks a lot for finding that .... 19:06:10 <hogepodge> o/ 19:06:10 <andrey-mp> i reviewed this some ago and i don't mind to merge it ) 19:06:28 <catherineD> I really appreciate all of our team work 19:06:41 <catherineD> I thing sslypushenko: just merged it ? 19:06:45 <sslypushenko> catherineD: Sorry for delay( It can be done a bit earlier) 19:07:05 <sslypushenko> now it looks good enough 19:07:14 <catherineD> sslypushenko: not a problem at all.... very good review ... 19:07:46 <sslypushenko> we need to refactor permission system 19:07:54 <sslypushenko> but for now it is good enough 19:08:15 <catherineD> sslypushenko: that is the kind of review we need ... it just happen that this time .. we want to shorten the time of exposure ... I will make a release to update the website this afternoon 19:08:30 <catherineD> moving on 19:09:39 <luzC> hello sorry to be late 19:10:16 <catherineD> BTW, I want to let everyone know that Luz has been working on documentation using sphinx ... this is what we want to do since day 1 and finaly get it ... THANK YOU luzC: 19:10:29 <catherineD> moving on ... 19:10:55 <catherineD> #topic Procduct version specification 19:11:41 <catherineD> #link Specitication to support product model with multi-versions. ( https://review.openstack.org/#/c/353903/ ) 19:12:52 <catherineD> sslypushenko: could you take a look at this patch ... 19:13:07 <sslypushenko> catherineD: yeap 19:13:41 <catherineD> this patch is a priorty because without laying down this foundation, all of our work is on hold . 19:13:48 <catherineD> sslypushenko: good 19:14:10 <catherineD> in that case let's look at andrey-mp: comment on line 51 .. 19:14:32 <sslypushenko> on it right now... 19:14:42 <catherineD> so task here is model a "1 to N" product to version relationship ... 19:14:59 <andrey-mp> it's not right 19:15:26 <sslypushenko> Basically, I agreed that Andrey's comment will simplify development 19:15:31 <andrey-mp> task is 'let user define several versions for product family' 19:15:52 <catherineD> andrey-mp: suggest to add a version column to the product table ... I see this as 1- 1 releationship between product and version ... 19:16:50 <catherineD> andrey-mp: the task is mode; " 1 product can have 0 to many version" 19:17:05 <catherineD> or I should say the requirement 19:17:18 <andrey-mp> yeah 19:17:27 <catherineD> from OpenStack Foundation 19:17:33 <andrey-mp> it's ok 19:17:42 <sslypushenko> Market place does not provide any uid for now, so I agreed with andrey-mp suggestion 19:17:49 <andrey-mp> why adding a version column doesn't suite this requirement? 19:18:06 <hogepodge> andrey-mp: I brought up the design to have a new product for every version, the DefCore Working Group did not like it 19:18:08 <catherineD> let me answer sslypushenko: question first 19:18:20 <sslypushenko> catherineD: it is easy... just think about product_version as product 19:18:26 <sslypushenko> that is it... 19:18:36 <catherineD> sslypushenko: that is the issue product_version is not a product 19:19:05 <sslypushenko> but technically there is no difference 19:19:06 <hogepodge> andrey-mp: On the basis that it adds complexity to the end user. The strong preference was to have a new version table that linked to product, and the test results linked to version. This way one product can have many versions 19:19:28 <catherineD> please read the long disucssion between me and andrey-mp: on http://eavesdrop.openstack.org/irclogs/%23refstack/%23refstack.2016-08-12.log.html 19:19:52 <catherineD> sslypushenko: techically it is an issue 19:20:03 <andrey-mp> hogepodge: we are talking about internal desing of DB. Will DefCore check internal implementation or they will see a ForntEnd? 19:20:15 <sslypushenko> hogepodge: catherineD: database is not exposing to the user 19:20:18 <catherineD> as I describe in http://eavesdrop.openstack.org/irclogs/%23refstack/%23refstack.2016-08-12.log.html 19:20:24 <sslypushenko> yeap andrey-mp +1 19:20:41 <sslypushenko> user will se product with versions 19:21:17 <hogepodge> andrey-mp: catherineD came to defcore to talk exactly about this problem, the internal representation, and this was the design we worked out 19:21:18 <sslypushenko> in database it will be separate record per product + version 19:21:21 <catherineD> can I go throught the scenario I did with andrey-mp: last Friday to descirbe why adding a version will not work 19:21:52 <catherineD> I will signal when I am done 19:23:25 <catherineD> first of all every one agree on the requirement that 1 product can have o to many versions right? 19:23:44 <andrey-mp> yes 19:23:51 <catherineD> sslypushenko: you? 19:24:15 <sslypushenko> yeap sure 19:24:19 <catherineD> ok 19:24:55 <catherineD> now if the version column is add to the "product" ... 19:25:48 <catherineD> Let say you create a product name "Mirantis OpenStack " https://www.openstack.org/marketplace/distros/ 19:26:08 <catherineD> sslypushenko: what are the version of the product (give me two versions) 19:26:20 <sslypushenko> 7.0 8.0 19:27:20 <catherineD> ok so last time you create a product in the product table name = Mirantis OpenDStack version=7.0 19:27:29 <catherineD> now with 8.0 19:28:07 <catherineD> with this model you will need to create an other entry to the product table with name=Miratnis OpenStack version=8.0 19:28:14 <catherineD> 2 issues here: 19:29:45 <catherineD> 1) this is actually 2 products 2) You can not guarantee that the product names will be the same for the 2 entries ... which refer to one product with 2 versions that should have the same product name .... 19:30:01 <catherineD> let me going to describe the model with versio ntable 19:30:19 <catherineD> with version table 19:31:38 <catherineD> the first time "Mirantis OpenStack" prodcut is created ... a producit entry is created in the productable .. a version (7.0) entry is created in the version table with foreign key point to the product 19:32:24 <catherineD> the second time for version 8.0 only additioanal entry is created in the version table to the same product FK ... 19:32:56 <catherineD> the product name (Mirantis OpenStack) is guarantee to be the same across all version ... 19:33:08 <catherineD> with that we model a 1-N relationship 19:33:09 <catherineD> done 19:34:00 <sslypushenko> catherineD that is clear, thank you 19:34:36 <andrey-mp> model issues with additional table: 1) why first version is created for product? 2) who will create this first version? 3) what version will be created for clouds? 4) if clouds will not have version - to which object link will be created? 19:34:39 <sslypushenko> and it should look to user exactly as you described 19:34:53 <catherineD> sslypushenko: yea 19:35:44 <hogepodge> andrey-mp: 1) every product has at least one version, 2) server can do it, 3) null/empty/none is ok 4) same as before, null/empty/none is ok, and it's a placeholder 19:35:48 <sslypushenko> but I also support andrey-mp statement that internally it will be easy to have separate record for each product+vesion 19:36:02 <catherineD> you can go to http://refstack.mybluemix.net/#/ and see the PoC how a prodcut would look like 19:36:23 <catherineD> create a product for yourself and then create version after that 19:36:55 <catherineD> sslypushenko: I feel like you still do not get the main issue 19:37:38 <sslypushenko> product id should be the same.... right? 19:37:46 <andrey-mp> hogepodge: link will always point to product+version (sensible or not), right? 19:37:49 <catherineD> the issue is if you have seperated product entry .. .how do you guarantee that the product name will be the same (keep in mind this is user input parameter ) 19:38:37 <sslypushenko> hm... I don't see issue here 19:38:49 <andrey-mp> catherineD: it depends on how to implement it in API - method add_version can be created for product. and business logic of RefStack can copy name... 19:38:56 <catherineD> sslypushenko: why should it be the same if the version column is in the product table .... it can only be the same when the version is in the version table and the product name is defined via FK link to a unique product entry 19:39:11 <sslypushenko> API can guarantee it 19:39:25 <catherineD> andrey-mp: please define the API for me 19:39:38 <catherineD> first what is the entry point of the API 19:39:57 <catherineD> to create 1) a product 2) a new version of a existing product 19:40:01 <andrey-mp> product_controller.action(add_version, params) 19:40:14 <andrey-mp> 1) is the same 19:40:35 <catherineD> I am talking about REST API 19:40:41 <catherineD> because that is user facing 19:40:51 <andrey-mp> me too 19:41:09 <catherineD> REST API look like this v1/products 19:41:36 <catherineD> so with a POST (creation) what is the schema for the body? 19:41:37 <sslypushenko> POST v1/products/action 19:42:00 <catherineD> no need for action 19:42:18 <catherineD> POST v1/products pretty much meand create a product 19:42:25 <catherineD> tell me the schema of the boby 19:43:14 <sslypushenko> it can be POST v1/products/action {'add_version': 8.0} 19:43:19 <andrey-mp> same as the actions for the vendors 19:43:32 <catherineD> let's do one thing at a time 19:43:34 <sslypushenko> but it does not really matter 19:43:46 <catherineD> concentrate on the create a prioduct first 19:43:48 <andrey-mp> moreover - additinal controller can be created for versions 19:44:12 <catherineD> sslypushenko: it matters because I do not see you see the issue that Isee 19:44:24 <sslypushenko> we are all agreed that from user view it should look like product can have 1 or move versions 19:44:27 <catherineD> please walk me thru what you think 19:44:39 <sslypushenko> catherineD: hogepodge andrey-mp right? 19:44:57 <catherineD> sslypushenko: agree but until you walk thru the scenario I do not see your case 19:45:04 <andrey-mp> catherineD: do you agree that REST API can be as you described in spec for DB implementation with additional field in product table? 19:45:19 <catherineD> andrey-mp: no 19:45:24 <catherineD> I don't see that 19:45:41 <andrey-mp> why not? 19:45:47 <sslypushenko> so... I don't see why we should spend so much time on implementation discussion... 19:46:18 <catherineD> sslypushenko: we have too .. .this is not implementation this is foundation of API layer 19:46:50 <catherineD> we need to discuss because this is blocking our work to achieve our goal for Newton 19:46:51 <hogepodge> andrey-mp: sslypushenko: creating a new product for every version is wrong. It's a bad model and is too easy to get wrong through a product name type 19:46:53 <hogepodge> type 19:46:54 <sslypushenko> DB it is foundation layer? 19:46:55 <hogepodge> typo 19:47:12 <catherineD> sslypushenko: yes 19:47:59 <catherineD> I am willing to try to understand all opinion but we need to discuss the reason and scenario leading to disagreement 19:48:07 <hogepodge> andrey-mp: the model should capture the model, not the business logic. it only makes sense to squash tables down like that if you really need performance, and afaik we aren't performance constrained. 19:48:14 <sslypushenko> hmm.... I guess that RefStack API is a Foundation layer... but ok 19:49:32 <catherineD> REST API is because that is how user (including RefStack UI ) can get to the data in refstack 19:49:44 <catherineD> so we need to be clear on the REST API 19:50:17 <andrey-mp> hogepodge: additional version table brings some problems with current product table. some fields in product table will not be needed, links will be published to the specific version. and in the future version table will be main and the product table will mean 'Product Family' 19:51:01 <catherineD> andrey-mp: sslypushenko: I would like to understand your thoughts ... so please let work on how the REST API and the model underneath it can support 1 product to N versions model 19:51:09 <sslypushenko> catherineD: that was my point of view... I don't get why DB layer should be considered as external artifact 19:51:40 <catherineD> andrey-mp: I do not see that is a reason why version table should not be add ... 19:52:23 <andrey-mp> because it is a splitting product information between two tables 19:52:27 <catherineD> sslypushenko: because DB layer can protect us from having wrong data 19:52:40 <sslypushenko> catherineD: point of view if very simple, if andrey-mp thinks that we can achieve our goal with less efforts - we should follow his recommendations 19:52:44 <catherineD> andrey-mp: forget about about additional table 19:53:21 <catherineD> let me understand you option by explain it to us from the use case (starting from REST API then entries in the table 0 19:53:49 <catherineD> we can have as many meetings as we want ... but we need to put this to rest one way or the other 19:53:50 <andrey-mp> ok. REST API can be the same as you described in spec - it's good. 19:54:12 <catherineD> I do not disagree with your option but I need to understand that it will suppor the 1 to N model 19:54:30 <andrey-mp> yes. it will support 19:54:59 <catherineD> andrey-mp: please walk me thru the product creation scenanio 19:55:45 <catherineD> sslypushenko: the issue is I support simplicity too ... but I am not sure that it will support the scenario ... 19:56:13 <andrey-mp> user creates product. he calls rest api post method for product. business logic creates product item in DB with provided version an other attributes. 19:56:36 <catherineD> 4 mins left ... sslypushenko: andrey-mp: will you be able to continie the discussion in #refstack 19:57:10 <sslypushenko> catherineD: I don't see a problem to follow scenario you described earlier using andrey-mp's suggestion 19:57:16 <andrey-mp> user adds version. he calls rest api as you defined in the spec. business logic adds one more item with another version and/or other attributes. 19:57:21 <catherineD> andrey-mp: ok so an entry with name=Mirantis OpenStack (MO) and version=6.0 is create in the prodcut table 19:57:42 <andrey-mp> sorry, i can't continue today... 19:57:59 <catherineD> andrey-mp: How about tomorrow? 19:58:06 <catherineD> this is blocking us ... 19:58:25 <catherineD> I am willing to work on your time table 19:59:07 <andrey-mp> or maybe 10-15 today 19:59:10 <andrey-mp> minutes 19:59:44 <catherineD> ok ... I think we can continuew here ... I do not think there are other people using this meeting IRC 20:00:07 <catherineD> continue on what we just discuss ... 20:00:40 <catherineD> we just create a product .. next we create a version of an existing product ... 20:00:52 <catherineD> what is the RESP API? 20:01:23 <andrey-mp> product api is the same as refstack has 20:01:37 <andrey-mp> versions api is the same as you described in the spec 20:01:54 <catherineD> we are ok with the product 20:01:59 <hogepodge> andrey-mp: we've been working on this for weeks now, the same issue around and around. We would like to see forward progress on this 20:03:10 <andrey-mp> hogepodge: i don't block the progress. i don't set -1 for reviews. I just posting my concerns about the future of this desicion. 20:03:45 <catherineD> so the API for version is v1/product/{product_id}/version with body schema show version name 20:04:13 <pvaneck> i dont think creating a product version table adds much complexity at all. 20:04:28 <pvaneck> Just not fond of the idea of duplicating product information in the product table for each version 20:05:00 <pvaneck> If a product doesn't have a version, then the user can leave the "Initial version" field blank when creating a product, then a single product_version entry will be created with a null version. Tests will be associated to that. 20:05:03 <catherineD> andrey-mp: do you agree with the API with version creation ? 20:05:13 <andrey-mp> pvaneck: maximum duplicated information is a name. description, cpid, all other will be different 20:05:48 <andrey-mp> catherineD: yes. I told you that described API for versions is good. 20:06:02 <andrey-mp> it's a small, consistent REST API. 20:06:21 <catherineD> the issue here is not duplicate or simplicity .. the real issue is adding a version column to the product table does not reflect the 1 to N model that we need to support 20:06:35 <andrey-mp> get/list/delete/update/create 20:06:50 <andrey-mp> i'm not agree 20:06:51 <catherineD> andrey-mp: OK the now we have an additional entry create in the product table right? 20:07:06 <andrey-mp> right. 20:07:12 <catherineD> let's keep one conversation 20:08:04 <catherineD> so for the first product entry product_id = 11111, product_name = MO, version=7.0 20:08:41 <catherineD> so you call v1/products/"11111"/version in the schema body version = 8.0 20:09:30 <catherineD> now you create an other entry product_id=22222, name=MO (I assume you copy the name), version = 8.0 20:09:56 <catherineD> so now there are 2 entries in the product table ... 20:10:00 <catherineD> andrey-mp: agree? 20:10:22 <andrey-mp> ok, this is a concern about REST API. it means that this API is not suitable. 20:11:09 <catherineD> then pls define a suitable REST API // 20:11:11 <andrey-mp> "calling v1/products/"11111"/version in the schema body version = 8.0" it is not suitable. 20:11:35 <catherineD> ok np what would be the API? 20:12:13 <andrey-mp> let me think - I will write my thoughts tomorrow in the review. 20:12:20 <catherineD> sure np 20:12:26 <andrey-mp> I can't define it right now. 20:12:34 <catherineD> I goal here is to understand your option 20:12:56 <catherineD> let me know whenever you are available ... 20:13:08 <catherineD> I just want to moving this forward .. 20:13:52 <catherineD> I know that we all want to make the right decision for RefStack ... and I really appreciate it ... 20:14:10 <andrey-mp> ssure 20:14:11 <catherineD> I guess we should end the meeting now ... 20:14:28 <catherineD> THANK YOU ALL soooo much! 20:14:29 <andrey-mp> I will post my thoughts before your morning 20:14:49 <catherineD> andrey-mp: THANK YOU!!! 20:15:00 <catherineD> #endmeeting