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