19:00:25 <catherineD> #startmeeting refstack
19:00:26 <openstack> Meeting started Tue Sep  6 19:00:25 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:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:31 <openstack> The meeting name has been set to 'refstack'
19:00:38 <sslypushenko> o/
19:00:58 <catherineD> sslypushenko: hello, how are you?
19:01:15 <sslypushenko> Fine! Thx!
19:01:43 <catherineD> #link meeting agenda and notes,  https://etherpad.openstack.org/p/refstack-meeting-16-09-06
19:01:44 <sslypushenko> Very sorry that I missed previous meeting(
19:01:55 <pvaneck> o/
19:01:59 <andrey-mp> o/
19:02:07 <catherineD> sslypushenko: np
19:02:46 <hogepodge> o/
19:02:50 <catherineD> #link meeting agenda and notes,  https://etherpad.openstack.org/p/refstack-meeting-16-09-06
19:03:23 <catherineD> #topic Implement additional properties Defcore waiver
19:03:41 <catherineD> #link  Implement additional properties Defcore waiver (  https://review.openstack.org/#/c/349213/ )
19:04:09 <catherineD> I think the spec is pretty much complete ...
19:04:11 <luzC> o/
19:04:39 <catherineD> hi luzC:  perfect timing https://etherpad.openstack.org/p/refstack-meeting-16-09-06
19:05:17 <catherineD> my only question is ...  Would it be better to implement this feature in a new script  rather than as an option in refstack-client.?
19:05:50 <catherineD> because 1) This is a short term solution. 2) The implementation is quite complicate and making refstack-clent become very big.  In addition, the code should be remove after the waiser expired.
19:06:15 <luzC> I like the idea of having it into the refstack-client but is up to you, hogepodge
19:06:22 <catherineD> the script still resides in refstack-client repository
19:07:26 <catherineD> refstack-client is quite big right now ... there are legacy code in there  today since we were not active in remove legacy code
19:07:29 <sslypushenko> catherineD:  I'd vote for single script... two scripts will make things look complicated
19:07:30 <luzC> also about the results right now I was just thinking on having a combined refstack JSON result file (with success test cases from original subunit file plus the re-runed TCs)
19:07:47 <hogepodge> As long as it's available and usable I don't have a strong opinion
19:08:11 <catherineD> andrey-mp: pvaneck: how about you?
19:08:13 <hogepodge> It would be nice to be able to add metadata to test results so we could identify things like the exception in the test result set, rather than have a weird split of that data
19:08:31 <catherineD> hogepodge: luzC: data would be the same ...
19:08:56 <catherineD> so the new script be just for testing and it will generate the json
19:09:22 <catherineD> refstack-client is used for uploading data ..
19:09:59 <catherineD> separate script will avoid us the trouble to clean up refstack-client after the waiver is expired ...
19:10:05 <andrey-mp> catherineD: sorry, I didn't read last version of this spec
19:11:24 <catherineD> since this would be a 2 steps process any way ... 1) you test it first time with refstack-client , 2) you can retest with a new script or with refstack-client with new options 3) upload data usign refstack-client
19:12:07 <luzC> andrey-mp spec is similar to the old version, the difference is on the tempest patch implementation -- now I'm patching only the tempest JSON schema
19:12:14 <catherineD> it is just an idea ... give it some thought .. we can revisit next week ... but I think the spec is near completion
19:12:53 <sslypushenko> btw... There is no other option except patching tempest?
19:14:48 <luzC> sslypushenko, no, the option of making a fix directly into Tempest was discussed and disregarded in the waiver discussion
19:14:48 <catherineD> hogepodge: yea adding meta data seems like something to consider ... will add that to our todo list
19:15:58 <catherineD> luzC: I think you still can start your implementation ( subroutines ..) while we revisit where the code should be next weeks?
19:16:11 <catherineD> I hope this does not stop you ...
19:16:29 <andrey-mp> sslypushenko: I suggested to fix downloaded tempest once at the installation process (and add a flag to config) but this way suggested as not suitable...
19:17:12 <catherineD> andrey-mp: the issue is the waiver (thus tempest fix) is not for everyone
19:17:33 <catherineD> this is only for a number of vendors
19:19:26 <andrey-mp> catherineD: i mean that some user can switch this block of code by same cli option
19:19:46 <catherineD> sslypushenko: The reason I think 2 scripts because the waiver portion of the script is not applicable to most of the vendors and the changes are at the tempest layers ...there will be a lot of code at refstack_client that
19:19:52 <catherineD> that need to be removed later
19:20:04 <andrey-mp> but we talked about it previously very much - lets stop )
19:20:33 <sslypushenko> catherineD:  I don't strong opinion here...
19:20:42 <catherineD> so we all agree to implement waiver as an option to refstack-client?
19:21:22 <sslypushenko> Whole idea sounds weird to me a bit... so I need to dig into details...
19:22:07 <catherineD> I do not mind either way .. .Just think that it will save us sometime when the waiver expired ...
19:23:01 <catherineD> do we want to make decision now ? or discuss again next week?
19:23:59 <sslypushenko> I don't mind on having waiver as an option to refstack-client
19:24:23 <catherineD> ok I think that is what andrey-mp: thinks too...
19:24:32 <andrey-mp> yeah
19:24:40 <hogepodge> catherineD: additional properties will always be available as part of nova 2.0 api
19:24:48 <catherineD> #agreed Implement waiver as an option to refstack-client
19:24:51 <hogepodge> catherineD: so there is potential to outlive short term
19:25:04 <hogepodge> catherineD: low and diminishing, though
19:25:17 <catherineD> yea I just want to point out something to the team
19:25:46 <catherineD> let's move on ...
19:26:22 <catherineD> now that we have decided to implement as an option
19:26:42 <catherineD> moving to the next topic ?
19:27:19 <luzC> yes, I agree... I'm submitting first version this week
19:27:32 <catherineD> alright
19:27:39 <catherineD> #topic Should we use the "meta" table to store verification info or add new column to" test" table
19:28:03 <catherineD> This is applicable to the 2 specs
19:28:18 <catherineD> #link     Specification to mark a test result as "used for verification". (  https://review.openstack.org/#/c/343954/  )
19:28:46 <catherineD> #link     Specification to associate test results to vendor products. (  https://review.openstack.org/#/c/332260/ )
19:28:56 <sslypushenko> catherineD:  basically there is no much to discuss
19:29:13 <sslypushenko> Both approaches will work
19:29:40 <sslypushenko> So it is up to the developer who will implement the spec
19:29:43 <catherineD> which way do we as a team want to implement ... that is a discussion point
19:29:45 <andrey-mp> it's very hard to store foreign_key in the meta field...
19:30:35 <sslypushenko> andrey-mp:  no, it is not) but... as I already told... both approaches work for me
19:30:36 <catherineD> andrey-mp: we did that today with meta key user ... but that may not be the best practice
19:31:26 <andrey-mp> for me - i prefer separate fields for data that can be used for searching/sorting
19:31:36 <sslypushenko> I just want ot point in spec than cons of alternative solution are not very real...
19:31:52 <sslypushenko> and one more thing
19:32:48 <sslypushenko> if we choose to not use meta table maybe we have to do some refactoring
19:33:02 <sslypushenko> to make things consistent
19:33:22 <catherineD> sslypushenko: the verification and public_version_id are new fields so now refactoring needed
19:33:54 <catherineD> sslypushenko:  you are right   guideline and target program will need refactoring
19:34:34 <andrey-mp> sslypushenko: good idea. and I think that first step is to create guideline table and move link to guideline from meta to separate field
19:34:35 <sslypushenko> good...
19:35:02 <sslypushenko> This approach works for me too...
19:35:07 <catherineD> andrey-mp: separate fields in the "test" table?
19:35:17 <andrey-mp> catherineD: yes
19:35:59 <andrey-mp> "link to guideline/target that was used to build list of tests"
19:36:05 <andrey-mp> something like this
19:36:18 <andrey-mp> as described in Alex's document
19:36:26 <catherineD> I would like to have the table change in one implementation  patch
19:36:41 <andrey-mp> catherineD: what table do you mean?
19:36:49 <catherineD> the test table
19:36:55 <andrey-mp> why?
19:37:15 <andrey-mp> it's ok if verification and link to product will be in one patch
19:37:25 <catherineD> so the two specs I have today will add verification_status and product_verion_id to the "test" table
19:37:32 <andrey-mp> but adding a guideline table and link to it - this is more complex task
19:38:23 <andrey-mp> ok. then I don't understand what exactly you want to see in this implementation patch
19:38:34 <catherineD> andrey-mp: ok we will make guideline and target to the next time ... but the longer we waite the more data we need to deal with ... sicne today people do link to guideline via meta
19:39:16 <andrey-mp> I think that people do link to guideline via UI...
19:39:32 <andrey-mp> how many people use REST API?
19:40:07 <andrey-mp> as I know - refstack-client can't do such thing
19:40:35 <catherineD> does not matter how many people use REST API as long as the API is public it should be consider carefully ..
19:41:12 <andrey-mp> but let's talk about guidelines later - right now you would to discuss other issues
19:41:25 <catherineD> andrey-mp: example ... we think that people will use UI and would not see the OpenID in the results list ... but someone did and point out that OpenID exposure ..
19:41:58 <catherineD> andrey-mp: agree to defer the gudeline update to later
19:42:30 <catherineD> #agreed Will discuss where to save guideline later
19:42:52 <catherineD> about filtering ...
19:43:24 <catherineD> should we implement it in patch or later ?
19:43:33 <andrey-mp> in this path
19:43:36 <andrey-mp> patch
19:43:39 <catherineD> ok
19:43:42 <andrey-mp> 4 additional lines
19:44:07 <andrey-mp> all logic already present in the 'list' method
19:45:05 <catherineD> #agreed Add filtering options  to  https://review.openstack.org/#/c/343954/   and https://review.openstack.org/#/c/332260/
19:46:07 <catherineD> Those are all the areas I want to discuss for those 2 patches
19:46:26 <catherineD> anything else before we move to the next topic ...
19:46:59 <catherineD> moving on then ...
19:47:04 <catherineD> #topic Pending reviews
19:47:23 <catherineD> #link     Fix missing dependency in refstack-client (  https://review.openstack.org/#/c/361189/  )
19:48:01 <catherineD> I am testing on Ubuntu 14 and 16 LTS ... and RedHat ..
19:48:12 <catherineD> not testing on SUSE
19:48:31 <catherineD> anyone else using SUSE?
19:48:39 <andrey-mp> i'm not
19:49:04 <sslypushenko> catherineD:  you can have SUSE in docker container
19:49:26 <sslypushenko> openSUSE atleast
19:49:40 <luzC> i'm not
19:50:06 <catherineD> sslypushenko: speaking of that ... refstack-client have changed a lot .... does the docker script need update?
19:50:57 <sslypushenko> what script you are talking about?)
19:51:24 <catherineD> sslypushenko: refstack-client ... sorry I should not change topic like that ..
19:51:40 <catherineD> let's talk about that later ...
19:51:46 <sslypushenko> ok
19:52:16 <catherineD> so for this patch I would just note that we tested it on Ubuntu and RedHat and then merge it ...?
19:52:57 <catherineD> I just do not have a SUSE vm handy
19:53:40 <catherineD> I hope that is OK for all of us
19:53:46 <catherineD> moving on ...
19:54:27 <catherineD> andrey-mp:     Authenticate user for update product with public key and signature  (  https://review.openstack.org/#/c/335877/ ) and     Add register cloud command (  https://review.openstack.org/#/c/335883/ )
19:54:45 <catherineD> I guess it need refactoring with the latest changes?
19:54:56 <catherineD> of adding product version
19:55:27 <andrey-mp> I guess it need some thoughts about usefulness of these patches )
19:56:17 <andrey-mp> right now 'register cloud' is not stated in any spec/document
19:56:20 <catherineD> andrey-mp: yup .. sorry for that ... but I think we need those implemenation ..
19:56:32 <andrey-mp> and I don't know is someone needs it or not
19:57:16 <catherineD> andrey-mp: you are right ... we need to document those ... thx for bringing this up
19:57:29 <andrey-mp> and your question about correctness of detected cpid...
19:57:30 <catherineD> I will put that as one of our todo list
19:58:00 <andrey-mp> ok
19:58:33 <catherineD> andrey-mp: I think detected cpid is needed when we in one day implement centralize testing ... that is our dream :-)
19:58:51 <catherineD> #topic Open Discussion
19:59:13 <andrey-mp> time is over...
19:59:25 <catherineD> pvaneck: Please share with us about jenkin failure ..
20:00:01 <pvaneck> real quick, functional gate jobs are now failing now that they are using xenial an dno longer trusty for it
20:00:23 <pvaneck> currently working on fixing it
20:00:39 <andrey-mp> do you need a help?
20:01:03 <luzC> do you have a link to take a look?
20:01:11 <pvaneck> andrey-mp, I don't think so, at least not yet
20:01:18 <pvaneck> should hopefully be a simple fix
20:01:23 <andrey-mp> pvaneck: ok
20:01:31 <pvaneck> can see failures here: #link http://logs.openstack.org/60/332260/8/check/gate-refstack-tox-db-py27-func-mysql-ubuntu-xenial/da49176/console.html
20:01:40 <catherineD> luzC: http://logs.openstack.org/54/343954/9/check/gate-refstack-tox-db-py27-func-mysql-ubuntu-xenial/2ccdf9c/
20:01:54 <luzC> thanks
20:02:20 <catherineD> alright
20:02:33 <catherineD> thank you all for joining the meeting ...
20:02:50 <catherineD> especially andrey-mp: sslypushenko: ... I know it is late for you ..
20:03:06 <catherineD> bye everyone ..
20:03:12 <catherineD> #endmeeting