19:00:17 <catherineD> #startmeeting refstack 19:00:18 <openstack> Meeting started Mon Nov 16 19:00:17 2015 UTC and is due to finish in 60 minutes. The chair is catherineD. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:22 <openstack> The meeting name has been set to 'refstack' 19:00:49 <catherineD> roll call 19:02:55 <pvaneck> o/ 19:03:41 <catherineD> pvaneck: hi 19:04:48 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-15-11-16 19:07:48 <pvaneck> not too many people today. Should we proceed on regardless? 19:08:19 <catherineD> sure let me send out an email to remind everyone 19:09:15 <catherineD> Let's start 19:09:35 <catherineD> #topic Refstack and subunit data 19:09:49 <hogepodge> o/ 19:10:33 <catherineD> hogepodge: hi .. we are about to discuss subunit data upload .. 19:10:57 <catherineD> #link meeting agenda and notes, \ https://etherpad.openstack.org/p/refstack-meeting-15-11-16 19:11:39 <catherineD> basically for the short term refstack-client need to provide this options ... the discussion is on what should be used for CPID 19:13:22 <catherineD> lookin at the agenda, I list 3 options there 1) refstack to create 2) user input 3) user to provide tempest.conf , refstack fetches the keystone url and then hash it 19:14:18 <pvaneck> i think just hashing the endpoint url is fine for most cases 19:14:19 <catherineD> none of the options is perfect in the sense that it will provide a unique CPID for each cloud 19:14:43 <hogepodge> pvaneck: that's the best option, and the one I prefer 19:14:55 <hogepodge> catherineD: something is better than nothing 19:14:56 <catherineD> ok done 19:14:58 <pvaneck> agreed 19:15:39 <catherineD> #agreed refstack-client will use the hash of endpoint url as CPID 19:16:06 <catherineD> for that do we ask the user to input url or we will get it from tempest.conf 19:16:28 <catherineD> I kind of like tempest,conf so we do not need to worry about format checking .. 19:17:26 <pvaneck> in the case of testing, it will already have the tempest.conf. In the case of uploading, I can see it going both ways 19:17:29 <pvaneck> hmm 19:18:12 <catherineD> I would prefer consistency between test and upload 19:18:14 <pvaneck> when we say hashing the endpoint, is this just as a fallback for if the identity endpoint isnt available? 19:18:28 <pvaneck> are we still going to try getting it from keystone? 19:19:29 <catherineD> pvaneck: yes for the case of test we only using url hash for the case we can not get the keystone service id ... for the case of upload that is the only way .. 19:20:29 <davidlenwell> o/ 19:20:39 <davidlenwell> I'm lurking .. but in another meeting thats almost finished 19:21:11 <catherineD> davidlenwell: sure link to the agenda https://etherpad.openstack.org/p/refstack-meeting-15-11-16 19:21:36 <hogepodge> pvaneck: I can confirm with at least one public cloud cpid isn't available, but keystone is the way to go 19:22:13 <hogepodge> pvaneck: although, it might be nice to have the option to hash the endpoint. I've been running defcore against a test cloud of mine and the cpid changes every time I stand it up, but the endpoint doesn't 19:22:35 <catherineD> hogepodge: Daryl also points out that it is not available for RackSpace public cloud ... 19:23:15 <davidlenwell> but aren't they not running kekystone are they? 19:23:28 <hogepodge> pvaneck: so it would be a way to have consistency across my test instances, but I'm saving relevant results so it's not a big deal 19:24:09 <catherineD> davidlenwell: not sure whether they are not running keystone or it is their policy not to expose the id ... 19:24:51 <dwalleck> Sorry, I keep getting this time messed up 19:24:54 <catherineD> hogepodge: How about your test that could not get CPID ... is the cloud running keystone? I thnk they must have to pass DefCore test 19:25:13 <pvaneck> hmm, would have to think about implementation. Right now it would be easiest to just hash the endpoint if the identity service id was unable to be retrived. 19:25:15 <davidlenwell> that was sort of what I was getting at 19:25:26 <hogepodge> catherineD: it's gets the cpid, it just changes every time I redeploy it 19:25:28 <catherineD> dwalleck: hey ... just in time ... we are taling about CPID and RackSpace cloud 19:25:55 <dwalleck> From the context I thought you might be 19:26:11 <catherineD> hogepodge: ok then that go the to fundamental issue that keystone service id may not be the parameter we should use 19:26:31 <catherineD> tailing --> talking :-) 19:27:15 <dwalleck> We're using an old Keystone v2-like Identity API, but the plan as I understand it is to roll to Keystone v3 "soon" 19:27:31 <catherineD> dwalleck: do you have any issue in getting CPID for the RackSpace public cloud? 19:28:09 <davidlenwell> well thats just it.. its keystone v2 "like" and not actually keystone v2 19:28:18 <davidlenwell> so currently they wouldn't pass the defcore tests 19:28:41 <catherineD> ic 19:28:47 <dwalleck> catherineD: How is the CPID generated? And is it returned with Keystone v2 by default? 19:29:48 <catherineD> currently CPID is the keystone endpoint id (v2) or keystone service id (v3)... 19:30:13 <dwalleck> I mostly deal with Nova at Rackspace, but these are questions I can pass along my Identity counterparts 19:30:54 <hogepodge> dwalleck: yeah, it's worth noting that keystone became a designated section a few months ago (meaning you have to run upstream keystone code for powered license) 19:30:56 <catherineD> at this meeting we are proposing that if refstack-client can not get the CPID it will generate one by hashing the keystone url 19:31:08 <davidlenwell> I like that idea catherineD 19:31:57 <dwalleck> hodgepodge: Totally understand. No one will be happier than I am once we've migrated to Keystone v3 19:32:44 <catherineD> great ... and in the short term refstack-client will provide option to upload data with subunit format data input ... this is in addition to the current JSON format ... 19:34:13 <catherineD> that is refstack-client will generate the JSON format data of pass tests only and send to RefStack server .... subunit data is not sent to the server ... 19:34:41 <catherineD> that get us to the next topic ... 19:35:20 <catherineD> #topic Long term -- should RefStack server accept subunit data format? 19:35:30 <davidlenwell> catherineD: I think that it should 19:35:40 <pvaneck> same 19:35:56 <davidlenwell> it can scrub it without processing the content and just drop sensitive data before its parsed 19:36:00 <catherineD> but subunit data will contain fail data and may be sensitive content 19:36:11 <davidlenwell> it doesn't have to be written to a disk 19:36:24 <davidlenwell> it can be srubed in memory before being parsed 19:36:36 <catherineD> how big should the memory be? 19:37:04 <catherineD> keep in mind that we encourage testing of all API test .... > 1600 test cases ... 19:37:16 <catherineD> with all the log ... 19:37:23 <davidlenwell> I don't know.. but thats still not going to be bigger then a few megabytes though right? 19:37:53 <catherineD> not sure but I can take a look and we can revisit later... 19:38:08 <catherineD> but it is a subject worth to discuss for long term .. 19:38:09 <davidlenwell> sure.. maybe look at how large the files are.. I don't think they are really that large 19:38:36 <catherineD> #action Catherine to investigate the size of subunit data 19:39:10 <davidlenwell> if it took up much space my vm I use for testing would have run out of disk space a long time ago 19:39:41 <catherineD> davidlenwell: so fare we only send JSON which is very small ... 19:40:03 <davidlenwell> yeah .. but file size wasn't the reason we chose to pre-parse and submit json 19:40:54 <catherineD> davidlenwell: yeah mostly because DefCore only wants us to accept pass data per board;s decision 19:41:40 <catherineD> see the IRC log of DefCore meeting on 2015/11/11: DefCore agreed that only pass tests are sent to RefStack server. 19:41:58 <davidlenwell> ahh.. well that does change things a little 19:42:36 <catherineD> yup any way we can evaluate from technical point of view ... but final decision will be on DefCore 19:42:42 <catherineD> moving on ... 19:42:58 <catherineD> #topic High priority bugs 19:43:16 <catherineD> #link Login issue https://bugs.launchpad.net/refstack/+bug/1504691 , https://bugs.launchpad.net/refstack/+bug/1514290 19:43:16 <openstack> Launchpad bug 1504691 in refstack "First login with OpenStackID is wonky" [High,Confirmed] - Assigned to Catherine Diep (cdiep) 19:43:17 <openstack> Launchpad bug 1514290 in refstack "Occasional Internal Server error when trying to log in" [High,Fix committed] - Assigned to Paul Van Eck (pvaneck-z) 19:44:28 <catherineD> The After pvaneck: 's https://review.openstack.org/#/c/242919/ ... login logout issues seem to be fixed .. 19:44:55 <pvaneck> yea login should finally be stable 19:46:06 <catherineD> Rocky opened this bug https://bugs.launchpad.net/refstack/+bug/1504691 ... so I will check with her and close it 19:46:06 <openstack> Launchpad bug 1504691 in refstack "First login with OpenStackID is wonky" [High,Confirmed] - Assigned to Catherine Diep (cdiep) 19:46:43 <catherineD> next high priority bug 19:46:53 <catherineD> #link RefStack should allow associating specific capabilities targets https://bugs.launchpad.net/refstack/+bug/1477392 19:46:54 <openstack> Launchpad bug 1477392 in refstack "RefStack should allow associating specific capabilities targets" [High,Confirmed] 19:47:59 <catherineD> right now a test was displayed at RefStack server ... we do not know which DefCore guideline the test is intented to be tested with .. 19:48:18 <catherineD> we would like to add tag to the test ... 19:48:46 <catherineD> do we agree that this is a high priority item? 19:48:53 <pvaneck> that would just be metadata associated with the test 19:49:26 <catherineD> hogepodge: are you interesting in having this feature? 19:49:45 <dwalleck> since capabilities are mapped to test ids, isn't that something we could sort out with the data we have already? 19:50:10 <davidlenwell> I think we can 19:50:19 <davidlenwell> dwalleck: 19:51:12 <catherineD> yeah as stated by pvaneck: it is a matter of adding metadata ... 19:51:54 <catherineD> but that means that the UI need to provide that display/option to add meta data ... 19:52:46 <catherineD> I was just wondering whether this should be priority while we have other items to work on with the limited developers we have 19:52:49 <davidlenwell> I've always wanted to create tools for reporting on the data in different ways.. 19:53:48 <catherineD> davidlenwell: so this should not be a high priroty item for now? 19:54:19 <davidlenwell> I dont know about high.. but I think its worth doing .. 19:54:46 <catherineD> #action Revisit bug RefStack should allow associating specific capabilities targets https://bugs.launchpad.net/refstack/+bug/1477392 in the next meeting 19:54:46 <openstack> Launchpad bug 1477392 in refstack "RefStack should allow associating specific capabilities targets" [High,Confirmed] 19:55:07 <catherineD> 6 mins left ,... let's get to the next topic 19:55:18 <catherineD> #topic High priority patches 19:55:33 <catherineD> #link https://review.openstack.org/#/c/245007/ ( Address regression and strengthen cpid checks) 19:56:24 <catherineD> could you please review that patch? I have tested it ... 19:56:43 <catherineD> refstack-client is currently not operational without this patch ... 19:57:01 <pvaneck> right, with this patch, it should also be easy to add the fallback cpid mechanism of hashing an endpoint 19:57:44 <catherineD> davidlenwell: could you please review .... 19:58:12 <catherineD> #topic Open discussion 19:58:15 <davidlenwell> yes.. I'll review now 19:58:20 <catherineD> in 2 mins :-) 19:58:27 <catherineD> davidlenwell: THANK YOU!!! 19:59:46 <catherineD> davidlenwell: pvaneck: dwalleck: hogepodge: Thank you very much!!! That is all the time we have for this week! 19:59:58 <catherineD> #endmeeting