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