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